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ITU-T RECOMMENDATION H.323 

VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS 
WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE 



Summary 

Recommendation H.323 describes terminals, equipment and services for multimedia communication 
over Local Area Networks (LAN) which do not provide a guaranteed quality of service. H.323 
terminals and equipment may carry real-time voice, data and video, or any combination, including 
videotelephony. 

The LAN over which H.323 terminals communicate, may be a single segment or ring, or it may be 
multiple segments with complex topologies. It should be noted that operation of H.323 terminals 
over the multiple LAN segments (including the Internet) may result in poor performance. The 
possible means by which quality of service might be assured on such types of LANs/internetworks is 
beyond the scope of this Recommendation. 

H.323 terminals may be integrated into personal computers or implemented in stand-alone devices 
such as videotelephones. Support for voice is mandatory, while data and video are optional, but if 
supported, the ability to use a specified common mode of operation is required, so that all terminals 
supporting that media type can interwork. This Recommendation allows more than one channel of 
each type to be in use. Other Recommendations in the H.323-Series include H.225.0 packet and 
synchronization, H.245 control, H.261 and H.263 video codecs, G.711, G.722, G.728, G.729, and 

G. 723 audio codecs, and the T.120-Series of multimedia communications protocols. 

This Recommendation makes use of the logical channel signalling procedures of Recommendation 

H. 245, in which the content of each logical channel is described when the channel is opened. 
Procedures are provided for expression of receiver and transmitter capabilities, so transmissions are 
limited to what receivers can decode, and so that receivers may request a particular desired mode 
from transmitters. Since the procedures of Recommendation H.245 are also used by 
Recommendation H.310 for ATM networks, Recommendation H.324 for GSTN, and V.70, 
interworking with these systems should not require H.242 to H.245 translation as would be the case 
for H.320 systems. 

H 323 terminals may be used in multipoint configurations, and may interwork with H.310 terminals 
on B-ISDN, H.320 terminals on N-ISDN, H.321 terminals on B-ISDN, H.322 terminals on 
Guaranteed Quality of Service LANs, H.324 terminals on GSTN and wireless networks, and V.70 
terminals on GSTN. 



Source ^ 

ITU-T Recommendation H.323 was prepared by ITU-T Study Group 15 (1993-1996) and was 
approved under the WTSC Resolution No. 1 procedure on the 8th of November 1996. 
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FOREWORD 

ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of 
telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of 
the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing 
Recommendations on them with a view to standardizing telecommunications on a worldwide basis. 

The World Telecommunication Standardization Conference (WTSC), which meets every four years, 
establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations 
on these topics. 

The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in 
WTSC Resolution No. 1. 

In some areas of information technology which fall within ITU-T's purview, the necessary standards are 
prepared on a collaborative basis with ISO and IEC. 



NOTE 



In this Recommendation, the expression "Administration" is used for conciseness to indicate both a 
telecommunication administration and a recognized operating agency. 



INTELLECTUAL PROPERTY RIGHTS 

The ITU draws attention to the possibility that the practice or implementation of this Recommendation may 
involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence, 
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others 
outside of the Recommendation development process. 

As of the date of approval of this Recommendation, the ITU had/had not received notice of intellectual 
property protected by patents, which may be required to implement this Recommendation. However 
impleme'ntors are cautioned that this may not represent the latest information and are therefore strongly urged 
to consult the TSB patent database. 
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All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, 
electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. 
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Recommendation H.323 

VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS 
WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE 

(Geneva, 1996) 



1 Scope 

This Recommendation covers the technical requirements for narrow-band visual telephone services 
defined in H 200/AV.120-Series Recommendations, in those situations where the transmission path 
includes one or more Local Area Networks (LAN), which may not provide a guaranteed Quality of 
Service (QOS) equivalent to that of N-ISDN. Examples of this type of LAN are: 

Ethernet (IEEE 802.3); 

Fast Ethernet (IEEE 802. 10); 

FDDI (non-guaranteed quality of service mode); 

Token Ring (IEEE 802.5). 
This Recommendation covers the case of visual telephone services in those situations where the 
transmission path includes one or more Local Area Networks (LAN), which are configured and 
managed to provide a guaranteed Quality of Service (QOS) equivalent to that of N-ISDN such that 
no additional protection or recovery mechanisms beyond those mandated by Recommendation 
H 320 need to be provided in the terminals. Pertinent parameters are the data error and loss 
properties and variation of transit delay. An example of a suitable LAN is: Integrated Services (IS) 
LAN: IEEE 802.9A Isochronous services with Carrier Sense Multiple Access with Collision 
Detection (CSMA/CD) Media Access Control (MAC) service. 

H 323 terminals may be used in multipoint configurations, and may interwork with H.310 terminals 
on B-ISDN H.320 terminals on N-ISDN, H.321 terminals on B-ISDN, H.322 terminals on 
Guaranteed Quality of Service LANs, H.324 terminals on GSTN and wireless networks, and V.70 
terminals on GSTN. See Figure 1. 

The scope of this Recommendation does not include the LAN itself, or the transport layer which 
may be used to connect various LANs. Only elements needed for interaction with the Switched 
Circuit Network (SCN) are within the scope of this Recommendation. The combination of the H.323 
Gateway, the H.323 terminal, and the out-of-scope LAN appears on the SCN as an H.320, H.310, 
H.324, or V.70 terminal. 

This Recommendation describes the components of an H.323 system. This includes Terminals, 
Gateways, Gatekeepers, Multipoint Controllers, Multipoint Processors and Multipoint Control Units. 
Control messages and procedures within this Recommendation define how these components 
communicate. Detailed descriptions of these components are contained in clause 6. 
The components described in this Recommendation consist of H.323 endpoints and H.323 entities. 
The endpoints can call and are callable according to the call set-up procedures of clause 8. The 
entities are not callable however, they can be addressed in order to perform their specific functions. 
For example, a terminal cannot place a cffl to a Gatekeeper however, the Gatekeeper is addressed as 
part of the call establishment procedures. 
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NOTE - A gateway may support one or more of the GSTN, N-ISDN and/or B-ISDN connections. 

Figure 1/H.323 - Interoperability of H.323 terminals 



2 Normative references 

The following ITU-T Recommendations and other references contain provisions which, through 
reference in this text, constitute provisions of this Recommendation. At the time of publication, the 
editions indicated were valid. All Recommendations and other references are subject to revision; all 
users of this Recommendation are therefore encouraged to investigate the possibility of applying the 
most recent edition of the Recommendations and other references listed below. A list of the currently 
valid ITU-T Recommendations is regularly published. 

[1] ITU-T Recommendation H.225.0 (1996), Media stream packetization and synchronization 
for visual telephone systems on non-guaranteed quality of service LANs. 

[2] ITU-T Recommendation H.245 (1996), Control protocol for multimedia communications. 

[3] CCITT Recommendation (1988), Pulse Code Modulation (PCM) of voice 

frequencies. 

[4] CCITT Recommendation G.722 (1988), 7 kHz audio-coding within 64 kbit/s. 

[5] ITU-T Recommendation G.723.1 (1996), Speech coders: Dual rate speech coder for 

multimedia communications transmitting at 5.3 and 6.3 kbit/s. 
[6] CCITT Recommendation G.728 (1992), Coding of speech at 16 kbit/s using low-delay code 

excited linear prediction. 
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[7] ITU-T Recommendation G.729 (1996), Coding of speech at 8 kbit/s using conjugate 

structure algebraic-code-excited linear-prediction (CS-ACELP). 
[8] ITU-T Recommendation H.261 (1993;, Video codec for audiovisual services at px 
64 kbit/s. 

[9] ITU-T Recommendation H.263 (1996), Video coding for low bit rate communication. 
[10] ITU-T Recommendation T.120 (1996), Transmission protocols for multimedia data. 
[1 1] ITU-T Recommendation H.320 (1996), Narrow-band visual telephone systems and terminal 
equipment. 

[12] ITU-T Recommendation H.321 (1996), Adaptation of H.320 visual telephone terminals to 
B-ISDN environments. 

[13] ITU-T Recommendation H.322 (1996), Visual telephone systems and terminal equipment 
for local area networks which provide a guaranteed quality of service. 

[14] ITU-T Recommendation H.324 (1996), Terminal for low bit rate multimedia 
communication. 

[15] ITU-T Recommendation H.310 (1996), Broadband and audiovisual communication systems 
and terminals. 

[16] ITU-T Recommendation Q.931 (1993), ISDN user-network interface layer 3 specification 
for basic call control. 

[17] ITU-T Recommendation Q.932 (1993), Generic procedures for the control of ISDN 
supplementary services. 

[18] ITU-T Recommendation Q.950 (1993), Supplementary services protocols, structure and 
general principles. 

[19] ISO/IEC 10646-1:1993, Information technology - Universal Multiple-Octet Coded- 

Character Set (USC) -Part I: Architecture and Basic Multilingual Plane. 
[20] CCITT Recommendation E. 1 64 (1 991), Numbering plan for the ISDN era. 

3 Definitions 

For the purposes of this Recommendation the definitions given in clause 3/H.225.0 [1] and 
clause 3/H.245 [2] apply along with those in this clause. These definitions apply to the LAN side 
only. Other terms may be appropriate when referring to the Switched Circuit Network (SCN) side. 
3.1 active MC: An MC that has won the master-slave determination procedure and is currently 
providing the multipoint control function for the conference. 

3 2 ad hoc multipoint conference: An Ad Hoc Multipoint conference was a point-to-point 
conference that had been expanded into a multipoint conference at some time during the call. This 
can be done if one or more of the terminals in the initial point-to-point conference contains an MC if 
the call is made using a Gatekeeper that includes MC functionality, or if the initial call is made 
through an MCU as a multipoint call bettyjen only two terminals. 

3 3 addressable: An H.323 entity on the LAN having a Transport Address. Not the same as 
being callable. A terminal or MCU is addressable and callable. A Gatekeeper is addressable but not 
callable. An MC or MP is neither callable nor addressable but is contained within an endpoint or 
Gatekeeper that is. 

3 4 audio mute: Suppressing of the audio signal of a single or all source(s). Send muting means 
that the originator of an audio stream mutes its microphone and/or does not transmit any audio signal 
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at all. Receive mute means that the receiving terminal ignores a particular incoming audio stream or 
mutes its loudspeaker. 

3.5 broadcast conference: A Broadcast conference is one in which there is one transmitter of 
media streams and many receivers. There is no bidirectional transmission of control or media 
streams. Such conferences should be implemented using LAN transport multicast facilities, if 
available. This conference type is for further study. 

3.6 broadcast panel conference: A Broadcast Panel conference is a combination of a 
Multipoint conference and a Broadcast conference. In this conference, several terminals are engaged 
in a multipoint conference, while many other terminals are only receiving the media streams. There 
is bidirectional transmission between the terminals in the multipoint portion of the conference and 
no bidirectional transmission between them and the listening terminals. This conference type is for 
further study. 

3.7 call: Point-to-point multimedia communication between two H.323 endpoints. The call 
begins with the call set-up procedure and ends with the call termination procedure. The call consists 
of the collection of reliable and unreliable channels between the endpoints. In case of interworking 
with some SCN endpoints via a gateway, all the channels terminate at the Gateway where they are 
converted to the appropriate representation for the SCN end system. 

3.8 call signalling channel: Reliable channel used to convey the call set-up and teardown 
messages (following Recommendation H.225.0) between two H.323 entities. 

3.9 callable: Capable of being called as described in clause 8. Terminals, MCUs and Gateways 
are callable, but Gatekeepers and MCs are not. 

3.10 centralized multipoint conference: A Centralized Multipoint conference is one in which 
ail participating terminals communicate in a point-to-point fashion with an MCU. The terminals 
transmit their control, audio, video, and/or data streams to the MCU. The MC within the MCU 
centrally manages the conference. The MP within the MCU processes the audio, video, and/or data 
streams, and returns the processed streams to each terminal. 

3 11 control and indication (C&I): End-to-end signalling between terminals, consisting of 
Control which causes a state change in the receiver, and Indication which provides for information 
as to the state or functioning of the system (see also Recommendation H.245 [2] for additional 
information and abbreviations). 

3.12 data: Information stream other than audio, video, and control, carried in the logical data 
channel (see Recommendation H.225.0 [1]). 

3 13 decentralized multipoint conference: A Decentralized Multipoint conference is one in 
which the participating terminals multicast their audio and video to all other participating terminals 
without using an MCU. The terminals are responsible for: 

a) summing the received audio streams; and 

b) selecting one or more of the received video streams for display. 

No audio or video MP is required in this case. The terminals communicate on their H.245 Control 
Channels with an MC which manages theconference. The data stream is still centrally processed by 
the MCS-MCU which may be within an Rff. 

3.14 endpoint: An H.323 terminal, Gateway, or MCU. An endpoint can call and be called. It 
generates and/or terminates information streams. 

3 15 gatekeeper: The Gatekeeper (GK) is an H.323 entity on the LAN that provides address 
translation and controls access to the local area network for H.323 terminals, Gateways and MCUs. 
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The Gatekeeper may also provide other services to the terminals, Gateways and MCUs such as 
bandwidth management and locating Gateways. 

3.16 gateway: An H.323 Gateway (GW) is an endpoint on the local area network which provides 
for real-time, two-way communications between H.323 Terminals on the LAN and other ITU 
Terminals on a wide area network, or to another H.323 Gateway. Other ITU Terminals include those 
complying with Recommendations H.310 (H.320 on B-ISDN), H.320 (ISDN), H.321 (ATM), H.322 
(GQOS-LAN), H.324 (GSTN), H.324M (Mobile), and V.70 (DSVD). 

3.17 H.323 Entity: Any H.323 component, including terminals, Gateways, Gatekeepers, MCs, 
MPs, and MCUs. 

3.18 H.245 control channel: Reliable Channel used to carry the H.245 control information 
messages (following H.245) between two H.323 endpoints. 

3.19 H.245 logical channel: Channel used to carry the information streams between two H.323 
endpoints. These channels are established following the H.245 OpenLogicalChannel procedures. An 
unreliable channel is used for audio, audio control, video, and video control information streams. A 
reliable channel is used for data and H.245 control information streams. There is no relationship 
between a logical channel and a physical channel. 

3.20 H.245 session: The part of the call that begins with the establishment of an H.245 Control 
Channel, and ends with the receipt of the H.245 EndSessionCommand or termination due to 
failure. Not to be confused with a call, which is delineated by the H.225.0 Setup and Release 
Complete messages. 

3.21 hybrid multipoint conference - centralized audio: A Hybrid Multipoint - Centralized 
Audio conference is one in which terminals multicast their video to other participating terminals, and 
unicast their audio to the MP for mixing. The MP returns a mixed audio stream to each terminal. 

3.22 hybrid multipoint conference - centralized video: A Hybrid Multipoint - Centralized 
Video conference is one in which terminals multicast their audio to other participating terminals, and 
unicast their video to the MP for switching or mixing. The MP returns a video stream to each 
terminal. 

3.23 information stream: A flow of information of a specific media type (e.g. audio) from a 
single source to one or more destinations. 

3.24 LAN address: The network layer address of an H.323 entity as defined by the 
(internetwork layer protocol in use (e.g. an IP address). This address is mapped onto the layer one 
address of the respective system by some means defined in the (inter)networking protocol. 

3.25 lip synchronization: Operation to provide the feeling that speaking motion of the displayed 
person is synchronized with his speech.. 

3.26 local area network (LAN): A shared or switched medium, peer-to-peer communications 
network that broadcasts information for all stations to receive within a moderate-sized geographic 
area, such as a single office building or a campus. The network is generally owned, used, and 
operated by a single organization. In the context of Recommendation H.323, LANs also include 
internetworks composed of several LANs that are interconnected by bridges or routes. 

3.27 mixed multipoint conference: X* Mixed Multipoint conference (see Figure 2) has some 
terminals (D, E and F) participating in a centralized mode while other terminals (A, B and C) are 
participating in a decentralized mode. A terminal is not aware of the mixed nature of the conference, 
only of the type of conference it is participating in. The MCU provides the bridge between the two 
types of conferences. 
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Figure 2/H.233 - Mixed multipoint conference 

3.28 multicast: A process of transmitting PDUs from one source to many destinations. The 
actual mechanism (i.e. IP multicast, multi-unicast, etc.) for this process may be different for different 
LAN technologies. 

3 29 multipoint conference: A Multipoint conference is a conference between three or more 
terminals. The terminals may be on the LAN or on the SCN. The multipoint conference shall always 
be controlled by an MC. Various multipoint conference types are defined in this clause but they all 
require a single MC per conference. They may also involve one or more H.231 MCUs on the SCN. 
A terminal on the LAN may also participate in an SCN multipoint conference by connecting via a 
Gateway to an SCN MCU. This does not require the use of an MC. 

3.30 multipoint control unit: The Multipoint Control Unit (MCU) is an endpoint on the local 
area network which provides the capability for three or more terminals and Gateways to participate 
in a multipoint conference. It may also connect two terminals in a point-to-point conference which 
may . later develop into a multipoint conference. The MCU generally operates in the fashion of an 
H.231 MCU, however, an audio processor is not mandatory. The MCU consists of two parts: a 
mandatory Multipoint Controller and optional Multipoint Processors. In the simplest case, an MCU 
may consist only of an MC with no MPs. 

3.31 multipoint controller: The Multipoint Controller (MC) is an H.323 entity on the local area 
network which provides for the control of three or more terminals participating in a multipoint 
conference. May also connect two terminals in a point-to-point conference which may later develop 
into a multipoint conference. The MC provides for capability negotiation with all terminals to 
achieve common levels of communications. It also may control conference resources such as who is 
multicasting video. The MC does not perform mixing or switching of audio, video and data. 

3.32 multipoint processor: The Multipoint Processor (MP) is an H.323 entity on the local area 
network which provides for the centralized processing of audio, video, and/or data streams in a 
multipoint conference. The MP provides for the mixing, switching, or other processing of media 
streams under the control of the MC. The MP may process a single media stream or multiple media 
streams depending on the type of conference supported. 

3.33 multi-unicast: A process of transferring PDUs where an endpoint sends more than one copy 
of a media stream, but to different endpoints. This may be necessary in networks which do not 
support multicast. 

334 point-to-point conference: A Point-to-Point conference is a conference between two 
terminals. It may be either directly between two H.323 terminals or between an H.323 terminal and 
an SCN terminal via a gateway. A call between two terminals (see Call). 
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3 35 RAS channel: Unreliable channel used to convey the registration, admissions, bandwidth 
change, and status messages (following Recommendation H.225.0) between two H.323 entities. 

3.36 reliable channel: A transport connection used for reliable transmission of an information 
stream from its source to one or more destinations. 

3.37 reliable transmission: Transmission of messages from a sender to a receiver using 
connection-mode data transmission. The transmission service guarantees sequenced, error-free, 
flow-controlled transmission of messages to the receiver for the duration of the transport connection. 
3 38 RTP session: For each participant, the session is defined by a particular pair of destination 
Transport Addresses (one LAN address plus a TSAP identifier pair for RTP and RTCP). The 
destination Transport Address pair may be common for all participants, as in the case of IP 
multicast, or may be different for each, as in the case of individual unicast network addresses. In a 
multimedia session, the media audio and video are carried in separate RTP sessions with their own 
RTCP packets. The multiple RTP sessions are distinguished by different transport addresses. 

3.39 switched circuit network (SCN): A public or private switched telecommunications 
network such as the GSTN, N-ISDN, or B-ISDN. 

3 40 terminal: An H.323 Terminal is an endpoint on the local area network which provides for 
real-time, two-way communications with another H.323 terminal, Gateway, or Multipomt Control 
Unit This communication consists of control, indications, audio, moving colour video pictures, 
and/or data between the two terminals. A terminal may provide speech only, speech and data, speech 
and video, or speech, data and video. 

3 41 transport address: The transport layer address of an addressable H.323 entity as defined by 
the (inter)network protocol suite in use. The Transport Address of an H.323 entity is composed of 
the LAN address plus the TSAP identifier of the addressable H.323 entity. 

3 42 transport connection: An association established by a transport layer between two H.323 
entities for the transfer of data. In the context of this Recommendation, a transport connection 
provides reliable transmission of information. 

3 43 TSAP identifier: The piece of information used to multiplex several transport connections 
of the same type on a single H.323 entity with all transport connections sharing the same LAN 
address (e.g. the port number in a TCP/UDP/IP environment). TSAP identifiers may be 
(pre)ass'igned statically by some international authority or may be allocated dynamically during the 
setup of a call. Dynamically assigned TSAP identifiers are of transient nature, i.e. their values are 
only valid for the duration of a single call. 

3.44 unicast: A process of transmitting messages from one source to one destination. 

3.45 unreliable channel: A logical communication path used for unreliable transmission of an 
information stream from its source to one or more destinations. 

3 46 unreliable transmission: Transmission of messages from a sender to one or more receivers 
by means of connectionless-mode data transmission. The transmission service is best-effort delivery 
of the PDU, meaning that messages transmitted by the sender may be lost, duplicated, or received 
out of order by (any of) the receivers). 

3 47 well-known TSAP identifier:^ TSAP identifier that has been allocated by an 
(international) authority that is in charge of the assignment of TSAP identifiers for z particular 
(internetworking protocol and the related transport protocols (e.g. the IANA for TCP and UDP port 
numbers). This identifier is guaranteed to be unique in the context of the respective protocol. 
3 48 zone- A Zone (see Figure 3) is the collection of all terminals (Tx), Gateways (GW), and 
Multipoint Control Units (MCU) managed by a single Gatekeeper (GK). A Zone includes at least 
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one terminal, and may or may not include Gateways or MCUs. A Zone has one and only one 
Gatekeeper. A Zone may be independent of LAN topology and may be comprised of multiple LAN 
segments which are connected using routes (R) or other devices. 

/ Zone 



Cn) (ok) (gw) 



-§ [mcu] 
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Figure 3/H.323 - Zone 



4 Symbols and abbreviations 

For the purpose of this Recommendation, the following symbols and abbreviations apply: 

4CIF 4 times CIF 

16CIF 16 times CIF 

ACF Admission Confirmation 

ARJ Admission Reject 

ARQ Admission Request 

BAS Bit rate Allocation Signal 

BCF Bandwidth Change Confirmation 

BCH Bose, Chaudhuri, and Hocquengham 

B-ISDN Broadband-Integrated Services Digital Network 



BRJ 


Bandwidth Change Reject 


BRQ 


Bandwidth Change Request 


C&I 


Control and Indication 


CID 


Conference Identifier 


CIF 


Common Intermediate Format 


DCF 


Disengage Confirmation 


DID 


Direct Inward Dialling 


DRQ 


Disengage Request 


ECS 


Encryption Control Signal 


EIV 


Encryption Initialization Vect&Y 


FAS 


Frame Alignment Signal 


FIR 


Full Intra Request 


GCF 


Gatekeeper Confirmation 


GK 


Gatekeeper 
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GQOS Guaranteed Quality of Service 

GRJ Gatekeeper Reject 

GRQ Gatekeeper Request 

GSTN General Switched Telephone Network 

GW Gateway 

IANA Internet Assigned Number Authority 

IP Internet Protocol 

IPX Internetwork Protocol Exchange 

IRQ Information Request 

IRR Information Request Response 

ISDN Integrated Services Digital Network 

ITU-T International Telecommunication Union - Telecommunication Standardization 
Sector 

LAN Local Area Network 

LCF Location Confirmation 

LCN Logical Channel Number 

LRJ Location Reject 

LRQ Location Request 

MC Multipoint Controller 

MCS Multipoint Communications System 

MCU Multipoint Control Unit 

MP Multipoint Processor 

MSN Multiple Subscriber Number 

N-ISDN Narrow-band-integrated Services Digital Network 

NACK Negative Acknowledge 

QCIF Quarter CIF 

RCF Registration Confirmation 

RRJ Registration Reject 

RRQ Registration Request 

RTP Real Time Protocol 

RTCP Real Time Control Protocol 

SBE Single Byte Extension V 

SCM Selected Communications Mode 

SCN Switched Circuit Network 

SPX Sequential Protocol Exchange 

SQCIF Sub QCIF 
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TCP 


Transport Control Protocol 


TSAP 


Transport Layer Service Access Point 


UCF 


Unregister Confirmation 


UDP 


User Datagram Protocol 


URJ 


Unregister Reject 


URQ 


Unregister Request 



5 Conventions 

In this Recommendation, the following conventions are used: 

"Shall" indicates a mandatory requirement. 

"Should" indicates a suggested but optional course of action. 

"May" indicates an optional course of action rather than a recommendation that something take 
place. 

References to clauses, subclauses, Annexes and Appendices refer to those items within this 
Recommendation unless another document is explicitly listed. For example, 1.4 refers to 1.4 of this 
Recommendation; 6.4/H.245 refers to 6.4 in Recommendation H.245. 

Where items exist on both the LAN and the SCN, references to the SCN item will be explicit. For 
example, an MCU is an H.323 MCU on the LAN, an SCN-MCU is an MCU on the SCN. 
This Recommendation describes the use of three different message types: H.245, RAS and Q.931. 
To distinguish between the different message types, the following conversion is followed. H.245 
message and parameter names consist of multiple concatenated words highlighted in bold typeface 
(maximumDelayJitter). RAS message names are represented by three letter abbreviations (ARQ). 
Q.93 1 message names consist of one or two words with the first letters capitalized (Call Proceeding). 

6 System description 

This Recommendation describes the elements of the H.323 components. These are Terminals, 
Gateways, Gatekeepers, MCs and MCUs. These components communicate through the transmission 
of Information Streams. The characteristics of these components are described in this clause. 

6.1 Information streams 

Visual telephone components communicate through the transmission of Information Streams. These 
Information Streams are classified into video, audio, data, communications control and call control 
as follows. 

Audio signals contain digitized and coded speech. In order to reduce the average bit rate of audio 
signals, voice activation may be provided. The audio signal is accompanied by an audio control 
signal. 

Video signals contain digitized and coded motion video. Video is transmitted at a rate no greater 
than that selected as a result of the capability exchange. The video signal is accompanied by a video 
control signal. 

Data signals include still pictures, facsimile, documents, computer files and other data streams. 
Communications control signals pass control data between remote like functional elements and are 
used for capability exchange, opening and closing logical channels, mode control and other 
functions that are part of communications control. 
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Call control signals are used for call establishment, disconnect and other call control functions. 

The information streams described above are formatted and sent to the network interface as 

described in Recommendation H.225.0. 

6.2 Terminal characteristics 

An example of an H.323 terminal is shown in Figure 4. The diagram shows the user equipment 
interfaces, video codec, audio codec, telematic equipment, H.225.0 layer, system control functions 
and the interface to the LAN. All H.323 terminals shall have a System Control Unit, H.225.0 layer, 
Network Interface and an Audio Codec Unit. The Video Codec Unit and User Data Applications are 
optional. 

Scope ofRec. H.323 



Video I/O equipment 



Audio I/O equipment 



User Data Applications 
T. 120, etc. 



System Control 
User Interface 



Video Codec 
H.261.H.263 



Audio Codec 
G.711.G.722, 
G.723, G.728, 
G.729 



Receive 

Path 

Delay 



System Control 



H.245 Control 



Call Control 
H.225.0 



RAS Control 
H.225.0 



H.225.0 
Layer 



Local Area 
Network 
Interface 
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Figure 4/H.323 - H.323 terminal equipment 



6.2.1 Terminal elements outside the scope of this Recommendation 

The following elements are not within the scope of this Recommendation and are therefore not 

defined within this Recommendation: 

Attached audio devices providing voice activation sensing, microphone and loudspeaker, 
telephone instrument or equivalent, multiple microphones mixers, and acoustic echo 
cancellation. 

Attached video equi^neiit proving cameras and monitors, and their control and selection, 
video processing to improve compression or provide split screen functions. 
Data applications and associated user interfaces which use T. 120 or other data services over 
the data channel 

Attached Network Interface, which provides the interface to the LAN, supporting 
appropriate signalling and voltage levels, in accordance with national and international 
standards. 
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Human user system control, user interface and operation. 

6.2.2 Terminal elements within the scope of this Recommendation 

The following elements are within the scope of this Recommendation, and are therefore subject to 

standardization and are defined within this Recommendation: 

The Video Codec (H.261, etc.) encodes the video from the video source (i.e. camera) for 
transmission and decodes the received video code which is output to a video display. 
The Audio Codec (G.711, etc.) encodes the audio signal from the microphone for 
transmission and decodes the received audio code which is output to the loudspeaker. 
The Data Channel supports telematic applications such as electronic whiteboards, still image 
transfer, file exchange, database access, audiographics conferencing, etc. The standardized 
data application for real-time audiographics conferencing is Recommendation T. 120. Other 
applications and protocols may also be used via H.245 negotiation as specified in 6.2.7. 
The System Control Unit (H.245, H.225.0) provides signalling for proper operation of the 
H.323 terminal. It provides for call control, capability exchange, signalling of commands 
and indications, and messages to open and fully describe the content of logical channels. 
H.225.0 Layer (H.225.0) formats the transmitted video, audio, data and control streams into 
messages for output to the network interface and retrieves the received video, audio, data, 
and control streams from messages which have been input from the network interface. In 
addition, it performs logical framing, sequence numbering, error detection and error 
correction as appropriate to each media type. 

6.2.3 LAN interface 

The LAN interface is implementation specific and is outside the scope of this Recommendation. 
However, the LAN interface shall provide the services described in Recommendation H.225.0. This 
includes the following: Reliable (e.g. TCP, SPX) end-to-end service is mandatory for the H.245 
Control Channel, the Data Channels, and the Call Signalling Channel. Unreliable (e.g. UDP, IPX) 
end-to-end service is mandatory for the Audio Channels, the Video Channels, and the RAS Channel. 
These services may be duplex or simplex, unicast or multicast depending on the application, the 
capabilities of the terminals, and the configuration of the LAN. 

6.2.4 Video codec 

The video codec is optional. All H.323 terminals providing video communications shall be capable 
of encoding and decoding video according to H.261 QCIF. Optionally, a terminal may also be 
capable of encoding and decoding video according to H.261 CIF or H.263 SQCIF, QCIF, CIF, 4CIF, 
and 16CIF If a terminal supports H.263 with CIF or higher resolution, it shall also support H.261 
CIF. All terminals which support H.263 shall support H.263 QCIF. The H.261 and H.263 codecs, on 
the LAN, shall be used without BCH error correction and without error correction framing. 
Other video codecs, and other picture formats, may also be used via H.245 negotiation. More than 
one video channel may be transmitted and/or received, as negotiated via the H.245 Control Channel. 
The H 323 terminal may optionally send more than one video channel at the same time, for example, 
to convey the speaker and a second video source. The H.323 terminal may optionally receive more 
than one video channel at the Same time,% example, to display multiple participants in a distributed 
multipoint conference. 

CIF and QCIF are defined in Recommendation H.261. SQCIF, 4CIF and 16CIF are defined in 
Recommendation H.263. For the H.261 algorithm, SQCIF is any active picture size less than QCIF, 
filled out by a black border, and coded in the QCIF format. For all these formats, the pixel aspect 
ratio is the same as that of the CIF format. 
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NOTE - The resulting picture aspect ratio for H.263 SQCIF is different from the other formats. 

The video bit rate, picture format and algorithm options that can be accepted by the decoder are 

defined during the capability exchange using H.245. The encoder is free to transmit anything that is 

within the decoder capability set. The decoder should have the possibility to generate requests via 

H 245 for a certain mode, but the encoder is allowed to simply ignore these requests if they are not 

mandatory modes. Decoders which indicate capability for a particular algorithm option shall also be 

capable of accepting video bit streams which do not make use of that option. 

H 323 terminals shall be capable of operating in asymmetric video bit rates, frame rates, and, if more 

than one picture resolution is supported, picture resolutions. For example, this will allow a CIF 

capable terminal to transmit QCIF while receiving CIF pictures. 

When each video logical channel is opened, the maximum operating mode to be used on that channel 
is signalled to the receiver in the H.245 OpenLogicalChannel message. The maximum mode 
signalled includes maximum picture format, algorithm options, maximum codec bit rate, etc. The 
header within the video logical channel indicates which mode is actually used for each picture, 
within the stated maximum. For example, a video logical channel opened for CIF format may 
transmit CIF, QCIF, or SQCIF pictures, but not 4CIF or 16CIF. A video logical channel opened with 
only the unrestrictedVector and arithmeticCoding options may use neither, either, or both options, 
but shall not use options which were not signalled. 
The video stream is formatted as described in Recommendation H.225.0. 

6.2.4.1 Terminal-based continuous presence 

H.323 terminals may receive more than one video channel, particularly for multipoint conferencing. 
In these cases, the H.323 terminal may need to perform a video mixing or switching function in 
order to present the video signal to the user. This function may include presenting the video from 
more than one terminal to the user. The H.323 terminal shall use H.245 simultaneous capabilities to 
indicate how many simultaneous video streams it is capable of decoding. The simultaneous, 
capability of one terminal should not limit the number of video streams which are multicast m a 
conference (this choice is made by the MC). 

6.2.5 Audio codec 

All H 323 terminals shall have an audio codec. All H.323 terminals shall be capable of encoding and 
decoding speech according to Recommendation G.711. All terminals shall be capable of transmitting 
and receiving A-law and u-law. A terminal may optionally be capable of encoding and decoding 
speech using Recommendations G.722, G.728, G.729, MPEG 1 audio, and G.723. The audio 
algorithm used by the encoder shall be derived during the capability exchange using H.245. The 
H 323 terminal should be capable of asymmetric operation for all audio capabilities it has declared 
within the same capability set, e.g. it should be able to send G.71 1 and receive G.728 if it is capable 
of both. 

The audio stream is formatted as described in Recommendation H.225.0. 

The H.323 terminal may optionally send more than one audio channel at the same time, for example, 
to allow two languages to be conveyed. 

Audio packets should be delivered to the feinsport layer periodically at an interval determined by the 
audio codec Recommendation in use (audio frame interval). The delivery of each audio packet shall 
occur no later than 5 ms after a whole multiple of the audio frame interval, measured from delivery 
of the first audio frame (audio delay jitter). Audio coders capable of further limiting their audio 
delay jitter may so signal using the H.245 maximumDelayJitter parameter of the h2250Capability 
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structure contained within a terminal capability set message, so that receivers may optionally reduce 
their jitter delay buffers. This is not the same as the RTCP interarrival jitter field. 
NOTE - The testing point for the maximum delay jitter is at the input to network transport layer. Network 
stack, network, driver, and interface card jitter is not included. 

6.2.5.1 Audio mixing 

H.323 terminals may receive more than one audio channel, particularly for multipoint conferencing. 
In these cases, the H.323 terminal may need to perform an audio mixing function in order to present 
a composite audio signal to the user. The H.323 terminal shall use H.245 simultaneous capabilities to 
indicate how many simultaneous audio streams it is capable of decoding. The simultaneous 
capability of one terminal should not limit the number of audio streams which are multicast in a 
conference. 

6.2.5.2 Maximum audio-video transmit skew 

To allow H.323 terminals to appropriately set their receive buffer(s) size, H.323 terminals shall 
transmit the h2250MaximumSkewIndication message to indicate the maximum skew between the 
audio and video signals as delivered to the network transport. h2250MaximumSkewIndication 
shall be sent for each pair of associated audio and video logical channels. This is not required for 
audio only or hybrid conferences Lip synchronization, if desired, shall be achieved via use of time- 
stamps. 

6.2.6 Receive path delay 

Receive path delay includes delay added to a media stream in order to maintain synchronization and 
to account for network packet arrival jitter. Media streams may optionally be delayed in the receiver 
processing path to maintain synchronization with other media streams. Further, a media stream may 
optionally be delayed to allow for network delays which cause packet arrival jitter: An H.323 
terminal shall not add delay for this purpose in its transmitting media path. 

Intermediate processing points such as MCUs or Gateways may alter the video and audio time tag 
information, and shall transmit appropriately modified audio and video time tags and sequence 
numbers, reflecting their transmitted signals. Receiving endpoints may add appropriate delay in the 
audio path to achieve lip synchronization. 

6.2.7 Data channel 

One or more data channels are optional. The data channel may be unidirectional or bidirectional 
depending on the requirements of the data application. 

Recommendation T.120 is the default basis of data interoperability between an H.323 terminal and 
other H.323, H.320, or H.310 terminals. Where any optional data application is implemented using 
one or more of the ITU-T Recommendations which can be negotiated via H.245, the equivalent 
T.120 application, if any, shall be one of those provided. A terminal that provides far-end camera 
control using H.281 and H.224 is not required to also support a T.120 far-end camera control 
protocol. 

Note that non-standard data applications^dataAppucationCapability = non-standard application, 
dataProtocolCapability = non-standard^ and Transparent User Data (dataApplicationCapability 
= userData application, dataProtocolCapability = transparent) may be used whether the 
equivalent T.120 application is provided or not. 

T.120 capability shall be signalled using dataApplicationCapability = tl20 application, 

dataProtocolCapability = separateLANStack. 

The Data channel is formatted as described in Recommendation H.225 .0. 
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6.2.7.1 T.120 data channels 

There are two ways of establishing a T.120 connection within the context of an H.323 call. The first 
is the establishment of the T.120 connection during an H.323 call as an inherent part of the call, 
using the procedures of H.245 for opening logical channels. The second is the establishment of the 
T.120 connection prior to placing the H.323 call. 

In the case where the H.323 call is established first, the normal call set-up procedures of 8.1 are 
followed. The capability exchange takes place, and a bidirectional logical channel shall be opened 
for the T.120 connection according to the normal H.245 procedures indicating that a new connection 
shall be created as described below. 

The opening of a bidirectional logical channel for T.120 may be initiated by either entity sending 
openLogicalChannel, and then following the bidirectional logical channel procedures of 
Recommendation H.245. 

To actually open the logical channel, the initiating entity shall send an openLogicalChannel 
message indicating that a T.120 data channel is to be opened in the 
forwardLogicalChannelParameters as well as in the reverseLogicalChannelParameters. The 
initiator may decide whether or not to include a transport address in the openLogicalChannel 
message If the peer (the responder) accepts this logical channel, it shall confirm the opening of the 
logical channel using openLogicalChannelAck. In the openLogicalChannelAck, the responder 
shall include a transport address to be used for set-up of the T.120 connection if it did not receive a 
transport address from the initiator. Otherwise, the transport address shall be absent. In both cases, 
the transport address for the T. 120 connection shall be carried in the separateStack parameter. 
The entity transmitting the transport address shall be prepared to accept a. T.120 connection on this 
transport address. The entity receiving the transport address shall initiate a T.120 connection set-up 
using the previously received transport address. 

In both the openLogicalChannel and the openLogicalChannelAck messages, the 
associateConference parameter shall be set to false. 

Recommendation T.120 shall follow the procedures of Recommendation T.123 for the protocol 
stack indicated in the dataProtocolCapability except that the transport addresses as described 
above shall be employed for connection set-up. The winner of the H.245 master/slave determination 
process shall have the option of being the upper node in the T.120 connection. 

NOTE -The T.120 operation after completion of the connection set-up is beyond the scope of this 
Recommendation. 

In the case where the T.120 connection is established first, the H.323 call is placed following the 
normal call set-up procedures of 8.1. The capability exchange takes place, and it is desired to 
associate the T.120 connection with the H.323 call. The procedures of Recommendation H.245 are 
used to open a bidirectional logical channel for T. 120 data as described below. 
The opening of a bidirectional logical channel for T.120 may be initiated by either entity by sending 
openLogicalChannel, and then following the bidirectional logical channel procedures of 
Recommenation H.245. The initiator of the set-up should include identification information for the 
already existing T.120 connection in the openLogicalChannel message to indicate to the peer which 
T. 120 connection (if there are several) is CSbe associated. 

To actually open the logical channel, the initiating entity shall send an openLogicalChannel 
message for a bidirectional logical channel indicating that a T.120 data channel is to be opened in 
the forwardLogicalChannelParameters as well as in the reverseLogicalChannelParameters. If 
the peer accepts this logical channel, it shall return an openLogicalChannelAck message to the 
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initiator in which it may include its local identification for the transport connection. In both 
messages, the associateConference parameter shall be set to true. 

As identification information, the local (dynamically instantiated) transport address of the initial 
transport connection of the T.120 connection should be provided in the separateStack parameter. In 
addition, the externalReference parameter may be used to provide further information on which 
T.120 connection is to be associated. 

If any of this identification information is not available to the initiator, it may omit the respective 
value(s). 

NOTE - If the transport address is not specified and the two endpoints share more than one T.120 connection 
it may be ambiguous for the recipient which T.120 connection is referred to. Implications of this ambiguity 
and steps to avoid it are for further study. 

6.2.8 H.24S control function 

The H 245 Control Function uses the H.245 Control Channel to carry end-to-end control messages 
governing operation of the H.323 entity, including capabilities exchange, opening and closing of 
logical channels, mode preference requests, flow control messages, and general commands and 
indications. 

H 245 signalling is established between two endpoints: an endpoint and an MC, or an endpoint and a 
Gatekeeper. The endpoint shall establish exactly one H.245 Control Channel for each call that the 
endpoint is participating in. This channel shall use the messages and procedures of Recommendation 
H 245 Note that a terminal, MCU, Gateway, or Gatekeeper may support many calls, and thus many 
H 245 Control Channels. The H.245 Control Channel shall be carried on logical channel 0. Logica 
channel 0 shall be considered to be permanently open from the establishment of the H.245 Contra 
Channel until the termination of this channel. The normal procedures for opening and closing logical 
channels shall not apply to the H.245 Control Channel. 

Recommendation H.245 specifies a number of independent protocol entities which support endpoint- 
to-endpoint signalling. A protocol entity is specified by its syntax (messages), semantics, and a set ot 
procedures which specify the exchange of messages and the interaction with the user. H.323 
endpoints shall support the syntax, semantics, and procedures of the following protocol entities: 
Master/slave determination. 
Capability Exchange. 
Logical Channel Signalling. 
Bidirectional Logical Channel Signalling. 
Close Logical Channel Signalling. 
Mode Request. 

Round Trip Delay Determination. 
Maintenance Loop Signalling. 
General commands and indications shall be chosen from the message set contained in 
Recommendation H.245. In addition, other command and indication signals may be sent which have 
been specifically defined to be transfer^ in-band within video, audio or data streams (see the 
appropriate Recommendation to determine if such signals have been defined). 
H 245 messages fall into four categories: Request, Response, Command, and Indication. Request and 
Response messages are used by the protocol entities. Request messages require a specific action by 
the receiver, including an immediate response. Response messages respond to a corresponding 
request. Command messages require a specific action, but do not require a response. Indication 



Recommendation H.323 (11/96) Superseded by a more recent version 



SM seded by a more recent^ on 



messages are informative only, and do not require any action or response. H.323 terminals shall 
respond to all H.245 commands and requests as specified in Annex A, and shall transmit indications 
reflecting the state of the terminal. 

H323 terminals shall be capable of parsing all H.245 MultimediaSysteraControlMessage 
messages and shall send and receive all messages needed to implement required functions and those 
optional functions which are supported by the terminal. Annex A contains a table showing which 
H 245 messages are mandatory, optional, or forbidden for H.323 terminals. H.323 terminals shall 
send the functionNotSupported message in response to any unrecognized request, response, or 
command messages that it receives. 

An H245 indication, userlnputlndication, is available for transport of user input alphanumeric 
characters from a keypad or keyboard, equivalent to the DTMF signals used in analogue telephony, 
or SBE number messages in Recommendation H.230. This may be used to manually operate remote 
equipment such as voice mail or video mail systems, menu-driven information services, etc. H.323 
terminals shall support the transmission of user input characters 0-9, and Transmission of 
other characters is optional. 

NOTE - If the encryption procedures of this Recommendation are in use, the H.245 Control Channel will not 
be encrypted. Users are therefore cautioned regarding the carriage of user data ,n the H.245 C™ 1 ™} ^*' 
the use of non-standard messages, and the confidentiality risk from traffic analysis of the H.245 Control 
Channel. 

Three H245 request messages conflict with RTCP control packets. The H245 
videoFastUpdatePicture, videoFastUpdateGOB and videoFastUpdateMB requests should be 
used instead of the RTCP control packets Full Intra Request (FIR) and Negative Acknowledgement 
(NACK). The ability to accept FIR and NACK is signalled during the H.245 capability exchange. 

6.2.8.1 Capabilities exchange 

Capabilities exchange shall follow the procedures of Recommendation H.245, which provides for 
separate receive and transmit capabilities, as well as a method by which the terminal may describe 
its ability to operate in various combinations of modes simultaneously. 

Receive capabilities describe the terminal's ability to receive and process incoming information 
streams. Transmitters shall limit the content of their transmitted information to that which he 
receiver has indicated it is capable of receiving. The absence of a receive capability indicates that the 
terminal cannot receive (is a transmitter only). 

Transmit capabilities describe the terminal's ability to transmit information streams. Transmit 
capabilities serve to offer receivers a choice of possible modes of operation, so mat the receiver may 
request the mode which it prefers to receive. The absence of a transmit capability indicates that the 
terminal is not offering a choice of preferred modes to the receiver (but it may still transmit anything 
within the capability of the receiver). 

The transmitting terminal assigns each individual mode the terminal is capable s of "operating in a 
number in a capabilityTable. For example, G.723 audio, G.728 audio, and CIF H.263 video would 
each be assigned separate numbers. 

These capability numbers ? are grouped into alternativeCapabilitySet structures. Each 
alternativeCapabilitySet indicates that\he terminal is capable of operating m exactly one mode 
Hsted In! ! the set. For example, an alternativeCapabilitySet listing {G.711, G.723, G.728} means 
that the terminal can operate in any one of those audio modes, but not more than one. 
These alternativeCapabilitySet structures are grouped into simultaneousCapabfflties structures. 
Each simultaneousCapabilities structure indicates a set of modes the terrninal is capable of using 
simultaneously. For example, a simultaneousCapabilities structure containing the two 
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alternativeCapabilitySet structures {H.261, H.263} and {G.711, G.723, G.728} means that the 
terminal can operate either of the video codecs simultaneously with any one of the audio codecs. The 
simultaneousCapabilities set { {H.261}, {H.261, H.263}, {G.711, G.723, G.728} } means the 
terminal can operate two video channels and one audio channel simultaneously: one video channel 
per H.261, another video channel per either H.261 or H.263, and one audio channel per either G.71 1, 
G.723, or G.728. 

NOTE - The actual capabilities stored in the capabilityTable are often more complex than presented here. 
For example each H.263 capability indicates details including the ability to support various picture formats at 
given minimum picture intervals, and the ability to use optional coding modes. For a complete descnption, 
see Recommendation H.245. 

The terminal's total capabilities are described by a set of capabilityDescriptor structures, each of 
which is a single simultaneousCapabilities structure and a capabilityDescriptorNumber. By 
sending more than one capabilityDescriptor, the terminal may signal dependencies between 
operating modes by describing different sets of modes which it can simultaneously use. For example, 
a terminal issuing two capabilityDescriptor structures, one { {H.261, H.263}, {G.711, G.723, 
G.728} } as in the previous example, and the other { {H.262}, {G.711} }, means the terminal can 
also operate the H.262 video codec, but only with the low-complexity G.71 1 audio codec. 
Terminals may dynamically add capabilities during a communication session by issuing additional 
capabilityDescriptor structures, or remove capabilities by sending revised capabilityDescriptor 
structures. All H.323 terminals shall transmit at least one capabilityDescriptor structure. 
Non-standard capabilities and control messages may be issued using the nonStandardParameter 
structure defined in Recommendation H.245. Note that while the meaning of non-standard messages 
is defined by individual organizations, equipment built by any manufacturer may signal any non- 
standard message, if the meaning is known. 

Terminals may re-issue capability sets at any time, according to the procedures of 
Recommendation H.245. 

6.2.8.2 Logical channel signalling 

Each logical channel carries information from a transmitter to one or more receivers, and is 
identified by a logical channel number which is unique for each direction of transmission. 
Logical channels are opened and closed using the openLogicalChannel and closeLogicalChannel 
messages and procedures of Recommendation H.245. When a logical channel is opened, the 
openLogicalChannel message fully describes the content of the logical channel, including media 
type, algorithm in use, any options, and all other information needed for the receiver to interpret the 
content of the logical channel. Logical channels may be closed when no longer needed. Open logical 
channels may be inactive, if the information source has nothing to send. 

Most logical channels in this Recommendation are unidirectional, so asymmetrical operation, in 
which the number and type of information streams is different in each direction of transmission, is 
allowed. However, if a receiver is capable only of certain symmetrical modes of operation, it may 
send a receive capability set that reflects its limitations, except where noted elsewhere in this 
Recommendation. Terminals may also be capable of using a particular mode in only one direction of 
transmission. Certain media types, incloding data protocols such as T.120, inherently require a 
bidirectional channel for their operation. In such cases a pair of unidirectional logical channels, one 
in each direction, may be opened and associated together to form a bidirectional channel using the 
bidirectional channel opening procedures of Recommendation H.245. Such pairs of associated 
channels need not share the same logical channel number, since logical channel numbers are 
independent in each direction of transmission. 
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Logical channels shall be opened using the following procedure: 

The initiating terminal shall send an OpenLogicalChannel message as described in 
Recommendation H.245. If the logical channel is to carry a media type using RTP (audio or video), 
the OpenLogicalChannel message shall include the mediaControlChannel parameter containing 
the transport address for the reverse RTCP channel. 

The responding terminal shall respond with an OpenLogicalChannelAck message as described in 
Recommendation H.245. If the logical channel is to carry a media type using RTP, the 
OpenLogicalChannelAck message shall include both the mediaTransportChannel parameter 
containing the RTP transport address for the media channel and the mediaControlChannel 
parameter containing the transport address for the forward RTCP channel. 

Media types (such as T.120 data) which do not use RTP/RTCP shall omit the 
mediaControlChannel parameters. 

If a corresponding reverse channel is opened for a given existing RTP session (identified by the RTP 
sessionID) the mediaControlChannel transport addresses exchanged by the OpenLogicalChannel 
process shall be identical to those used for the forward channel. Should a collision occur where both 
ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject 
the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel 
attempt may then be retried at a later time. 

6.2.8.3 Mode preferences 

Receivers may request transmitters to send a particular mode using the H.245 requestMode 
message, which describes the desired mode. Transmitters should comply if possible. 
An endpoint receiving the multipointModeCommand from the MC shall then comply with all 
requestMode commands, if they are within its capability set. Note that in a decentralized 
conference, as in a centralized conference, all terminal requestMode commands are directed to the 
MC. The MC may grant the request or not; the basis for this decision is left to the manufacturer. 

6.2.8.4 Master-slave determination 

The H245 Master-slave determination procedures are used to resolve conflicts between two 
endpoints which can both be the MC for a conference, or between two endpoints which are 
attempting to open a bidirectional channel. In this procedure, two endpoints exchange random 
numbers in the H.245 masterSlaveDetermination message, to determine the master and slave 
endpoints. H.323 endpoints shall be capable of operating in both master and slave modes. The 
endpoints shall set terminalType to the value specified in Table 1 below and set 
statusDeterminationNumber to a random number in the range 0 to 2 -1. Only one random 
number shall be chosen by the endpoint for each call, except in the case of identical random 
numbers, as described in Recommendation H.245. 
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Table 1/H.323 - H.323 terminal types for H.245 master-slave determination 



TerminalType Value Table 


H.323 Entity 




Feature set 


Terminal 


Gateway 


Gatekeeper 


MCU 


Entity with No MC 


50 


60 


NA 


NA 


Entity contains an MC but no Mr 


70 


80 


120 


160 


Entity contains MC with data MP 


NA 


90 


130 


170 


Entity contains MC with data and audio MP 


NA 


100 


140 


180 


Entity contains MC with data, audio, and video 
MP 


NA 


110 


150 


190 



The Active MC in a conference shall use a value of 240. Cascaded MCs are for further study. 
If a single H.323 entity can take part in multiple calls, then the value used for terminalType in the 
master-slave determination process shall be based on the features that the H.323 entity has assigned 
or will assign to the call in which it is being signalled. 

An MC that is already acting as an MC shall always remain the active MC. Therefore, once an MC 
has been selected as the active MC in a conference, it shall use the Active MC value for all 
subsequent connections to the conference. 

If no MC is active and the entities are of the same type, then the H.323 entity with the highest 
feature set (as shown in Table 1) shall win the master-slave determination. If no MC is active and the 
entities are of different types, then an MC that is located in an MCU shall have priority over an MC 
that is located in a Gatekeeper, which shall have priority over an MC that is located in a Gateway, 
which in turn shall have priority over an MC located in a terminal. 

If an H.323 entity can be associated with two or more of the classifications shown in Table 1, then it 
should use the highest value for which it qualifies. 

6.2.8.5 Timer and counter values 

All timers defined in Recommendation H.245 should have periods of at least as long as the 

maximum data delivery time allowed by the data link layer carrying the H.245 Control Channel, 

including any retransmissions. 

The H.245 retry counter N100 should be at least 3. 

Procedures relating to H.245 protocol error handling are covered in 8.6. 

6.2.9 RAS signalling function 

The RAS signalling function uses H.225.0 messages to perform registration, admissions, bandwidth 
changes, status, and disengage procedures between endpoints and Gatekeepers. The RAS Signalling 
Channel is independent from the Call Signalling Channel and the H.245 Control Channel. H.245 
open logical channel procedures are not used to establish the RAS Signalling Channel. In LAN 
environments that do not have a Gatekeeper, the RAS Signalling Channel is not used. In LAN 
environments which contain a Gatekeeper (a Zone), the RAS Signalling Channel is opened between 
the endpoint and the Gatekeeper. The RAS Signalling Channel is opened prior to the establishment 
of any other channels between H.323 endpoints. This channel is described in detail in clause 7. 

6.2.10 Call signalling function 

The call signalling function uses H.225.0 call signalling to establish a connection between two 
H.323 endpoints. The Call Signalling Channel is independent from the RAS Channel and the H.245 
Control Channel. H.245 open logical channel procedures are not used to establish the Call Signalling 
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Channel. The Call Signalling Channel is opened prior to the establishment of the H.245 Channel and 
any other logical channels between H.323 endpoints. In systems that do not have a Gatekeeper, the 
Call Signalling Channel is opened between the two endpoints involved in the call. In systems which 
contain a Gatekeeper, the Call Signalling Channel is opened between the end point and the 
Gatekeeper, or between the endpoints themselves as chosen by the Gatekeeper. This channel is 
described in detail in clause 7. 

6.2.11 H.225.0 layer 

Logical channels of video, audio, data or control information are established according to the 
procedures of Recommendation H.245. Logical channels are unidirectional, and are independent in 
each direction of transmission. Some logical channels, such as for data, may be bidirectional, and are 
associated through the bidirectional open logical channel procedure of Recommendation H.245. Any 
number of logical channels of each media type may be transmitted, except for the H.245 Control 
Channel of which there shall be one per call. In addition to the logical channels, H.323 endpoints use 
two signalling channels for call control, and Gatekeeper related functions. The formatting used for 
these channels shall conform to Recommendation H.225.0. 

6.2.1 1.1 Logical channel numbers 

Each logical channel is identified by a Logical Channel Number (LCN), in the range 0 to 65 535, 
which serves only to associate logical channels with the transport connection. Logical channel 
numbers are selected arbitrarily by the transmitter, except that logical channel 0 shall be permanently 
assigned to the H.245 Control Channel. The actual Transport Address that the transmitter shall 
transmit to, shall be returned by the receiver in the openLogicalChannelAck message. 

6.2.11.2 Logical channel bit rate limits 

A logical channel's bandwidth shall have an upper limit specified by the minimum of the endpoint's 
transmit capability (if present) and the receiving endpoint's receive capability. Based on this limit, an 
endpoint shall open a logical channel at a bit rate at or below this upper limit. A transmitter shall 
transmit an information stream within the logical channel at any bit rate at or below the open logical 
channel bit rate. The limit applies to the information streams which are the content of the logical 
channel(s), not including RTP headers, RTP payload headers and LAN headers and other overhead. 
H.323 endpoints shall obey to the flowControlCommand message of H.245, which commands a 
limit to the bit rate of a logical channel or the aggregate bit rate of all logical channels. H.323 
endpoints that want to limit the bit rate of a logical channel, or the aggregate bit rate of all logical 
channels should send the flowControlCommand message to the transmitting endpoint. 
When the terminal has no information to send in a given channel, the terminal shall send no 
information. Fill data shall not be sent on the LAN in order to maintain a specific data rate. 



6.3 Gateway characteristics 

The Gateway shall provide the appropriate translation between transmission formats (for example 
H.225.0 to/from H.221) and between communications procedures (for example H.245 to/from 
H 242). The Gateway shall also perform call set-up and clearing on both the LAN side and the SCN 
side. Translation between video, audio, afcd data formats may also be performed in the Gateway. In 
general, the purpose of the Gateway (when not operating as an MCU) is to reflect the characteristics 
of a LAN endpoint to an SCN endpoint, and the reverse, in a transparent fashion. 
An H.323 endpoint may communicate with another H.323 endpoint on the same LAN directly and 
without involving a Gateway. The Gateway may be omitted if communications with SCN terminals 
(terminals not on the LAN) is not required. It may also be possible for a terminal on one segment of 
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the LAN to call out through one Gateway and back onto the LAN through another Gateway in order 
to bypass a router or a low bandwidth link. 

The Gateway has the characteristics of an H.323 Terminal or MCU on the LAN, and of the SCN 
terminal or MCU on the SCN. The choice of terminal or MCU is left to the manufacturer. The 
Gateway provides the necessary conversion between the different terminal types. Note that the 
Gateway may initially operate as a terminal, but later using H.245 signalling begin to operate as an 
MCU for the same call that was initially point-to-point. Gatekeepers are aware of which terminals 
are Gateways since this is indicated when the terminal/Gateway registers with the Gatekeeper. 
A Gateway which passes T.120 data between the SCN and the LAN may contain a T.120 MCS 
Provider which connects the T.120 MCS Providers on the LAN to the T.120 MCS Providers on the 
SCN. 

Four examples of an H.323 Gateway are shown in Figure '5. The diagrams show the H.323 terminal 
or MCU function, the SCN terminal or MCU function, and the conversion function. The H.323 
terminal function has the characteristics described in 6.2. The H.323 MCU function has the 
characteristics described in 6.5. The Gateway appears to the other H.323 terminals on the LAN as 
one or more H.323 terminals, or an H.323 MCU. It communicates with the other H.323 terminals 
using the procedures in this Recommendation. 

The SCN terminal or MCU function has the characteristics described in the appropriate 
Recommendation (H.310, H.320, H.321, H.322, H.324, V.70, GSTN or ISDN speech only 
terminals). The Gateway appears to the terminals on the SCN as one or more of the same terminal 
types or MCUs. It communicates to another terminal on the SCN using the procedures described in 
the appropriate Recommendation for that terminal. SCN signalling procedures are beyond the scope 
of this Recommendation, including such topics as whether the H.323 Gateway appears as a terminal 
or a network to the SCN. Note that a Gateway may convert H.323 directly to H.324 or H.310 
without going to H.320. 

Gateways supporting interworking with speech only terminals on GSTN or ISDN should generate 
and detect DTMF signals corresponding to H.245 userlnputlndications for 0-9, *, and #. 
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Figure 5/H.323 - H.323 gateway configurations 



The conversion function provides the necessary conversion of transmission format, control, audio, 
video and/or data streams between the different terminal Recommendations. At a nunimum, the 
Gateway shall provide a conversion function for the transmission format, call set-up signals and 
procedures, and communications control signals and procedures. When required, the Gateway shall 
orovide for H 242 to H.245 conversion. The Gateway performs the appropriate conversion between 
die H225.0 Call Signalling and the SCN signalling system (Q.931, Q.2931, etc.). The conversion 
between Q.931 messages on the LAN and Q.931 messages on the SCN is described m Appendix A. 
All Q931 signalling received by the Gateway from an ISDN endpoint and not applicable to the 
Gateway should be passed through to the LAN endpoint, and vice versa. This signalling includes 
O 932 and Q 950-Series messages. This will allow H.323 endpoints to implement the Supplementary 
Services defined in those Reconimendations. The handling of other SCN call signalling systems is 
for further study. ^ 

This Recommendation describes the connection of one H.323 terminal on the LAN to one external 
terminal on the SCN through the Gateway: The actual number of H.323 terminals that can 
communicate through the Gateway is not subject to standardization. Similarly, the number of SCN 
connections, number of simultaneous independent conferences, audio/yideo/data conversion 
functions, and inclusion of multipoint functions is left to the manufacturer If the Gateway includes 
an MCU function on the LAN side, that function shall be an H.323 MCU on the LAN side. If the 
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Gateway includes an MCU function on the SCN side, it may appear as an H.231/H.243 MCU, or as 
an MCU for H.310 or H.324 systems (these MCUs are indicated as for further study in the respective 
Recommendations) on the SCN side. 

A Gateway may be connected via the SCN to other Gateways to provide communication between 
H.323 terminals which are not on the same LAN. 

Equipment which provides transparent interconnection between LANs without using H.320 (such as 
routes and remote dial in units) are not Gateways as defined within the scope of this 
Recommendation. 



6.4 Gatekeeper characteristics 

The Gatekeeper, which is optional in an H.323 system, provides call control services to the H.323 
endpoints. More than one Gatekeeper may be present and communicate with each other in an 
unspecified fashion. The Gatekeeper is logically separate from the endpoints, however, its physical 
implementation may coexist with a terminal, MCU, Gateway, MC, or other non-H.323 LAN device. 

When it is present in a system, the Gatekeeper shall provide the following services: 

Address Translation - The Gatekeeper shall perform alias address to Transport Address 
translation. This should be done using a translation table which is updated using the 
Registration messages described in clause 7. Other methods of updating the translation table 
are also allowed. 

Admissions Control - The Gatekeeper shall authorize LAN access using ARQ/ACF/ARJ 
H.225.0 messages. This may be based on call authorization, bandwidth, or some other 
criteria which is left to the manufacturer. It may also be a null function which admits all 
requests. 

Bandwidth Control - The Gatekeeper shall support BRQ/BRJ/BCF messages. This may be 
. based on bandwidth management. It may also be a null function which accepts all requests 
for bandwidth changes. 

Zone Management - The Gatekeeper shall provide the above functions for terminals, 
MCUs, and Gateways which have registered with it as described in 7.2. 

The Gatekeeper may also perform other optional functions such as: 

Call Control Signalling - The Gatekeeper may choose to complete the call signalling with 
the endpoints and may process the call signalling itself. Alternatively, the Gatekeeper may 
direct the endpoints to connect the Call Signalling Channel directly to each other. In this 
manner, the Gatekeeper can avoid handling the H.225.0 call control signals. The Gatekeeper 
may have to act as the network as defined in Recommendation Q.931 in order to support 
supplementary services. This operation is for further study. 

Call Authorization - Through the use of the H.225.0 signalling, the Gatekeeper may reject 
calls from a terminal due to authorization failure. The reasons for rejection may include, but 
are not limited to, restricted access to/from particular terminals or Gateways, and restricted 
access during certain periods of time. The criteria for determining if authorization passes or 
fails is outside the scope of this Recommendation. 

Bandwidth Management - Contrfft of the number of H.323 terminals permitted simultaneous 
access to the LAN. Through the use of the H.225.0 signalling, the Gatekeeper may reject 
calls from a terminal due to bandwidth limitations. This may occur if the Gatekeeper 
determines that there is not sufficient bandwidth available on the network to support the call. 
The criteria for determining if bandwidth is available is outside the scope of this 
Recommendation. Note that this may be a null function, i.e. all terminals are granted access. 
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This function also operates during an active call when a terminal requests additional 



Call Management - For example, the Gatekeeper may maintain a list of ongoing H.323 
calls. This information may be necessary to indicate that a called terminal is busy, and to 
provide information for the Bandwidth Management function. 
Gatekeeper management information data structure - For further study. 
Bandwidth reservation for terminals not capable of this function - For further study. 
Directory services - For further study. 

In order to support ad hoc Multipoint Conferences, the Gatekeeper may choose to receive the H.245 
Control Channels from the two terminals in a point-to-point conference. When the conference 
switches to a multipoint conference, the Gatekeeper can redirect the H.245 Control Channel to an 
MC. The Gatekeeper need not process the H.245 signalling; it only needs to pass it between the 
terminals or the terminals and the MC. 

LANs which contain Gateways should also contain a Gatekeeper in order to translate incoming 
E.164 addresses into Transport Addresses. 

H.323 entities that contain a Gatekeeper shall have a mechanism to disable the internal Gatekeeper 
so that when there are multiple H.323 entities that contain a Gatekeeper on a LAN, the H.323 
entities can be configured into the same Zone. 

6.5 Multipoint controller characteristics 

The MC provides control functions to support conferences between three or more endpoints in a 
multipoint conference. The MC carries out the capabilities exchange with each endpoint in a 
multipoint conference. The MC sends a capability set to the endpoints in the conference indicating 
the operating modes in which they may transmit. The MC may revise the capability set that it sends 
to the terminals as a result of terminals joining or leaving the conference, or for other reasons. 

In this manner, the MC determines the Selected Communication Mode (SCM) for the conference. 
The SCM may be common for all endpoints in the conference. Alternatively, some endpoints may 
have a different SCM than other endpoints in the conference. The manner in which the MC 
determines an SCM is not within the scope of this Recommendation. 

As part of multipoint conference set-up, an endpoint will become connected to an MC on its H.245 
Control Channel. This connection may occur: 

- via an explicit connection with an MCU; 

via an implicit connection to the MC within a Gatekeeper; 

via an implicit connection to the MC within another terminal or Gateway in the multipoint 
conference; 

- via an implicit connection through a Gatekeeper to an MCU. 

The choice of conference mode (e.g. decentralized or centralized) occurs after connection with the 
MC using H.245 signalling. The choice of conference mode may be limited by the capability of the 
endpoints or the MC. 

The MC may be located within a Gatekeeper, Gateway, terminal, or MCU. See Figure 6. 
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NOTE - Gateway, Gatekeeper and MCU can be a single device. 

Figure 6/H.323 - Possible locations of MC and MP in H.323 system 



An MC within a terminal is not callable. It can be included in the call in order to process the H.245 
signalling to support ad hoc multipoint conferences. In this case, there may be no distinction 
between the MC and the H.245 Control Function (see 6.2.8) of the terminal. Communications 
between them is outside the scope of this Recommendation. 

An MC located with the Gatekeeper is not callable; however, an MCU located with a Gatekeeper is 
callable. An MCU located with a Gatekeeper functions as an independent MCU. An MC located 
with a Gatekeeper may be used to support ad hoc multipoint conferences when the Gatekeeper 
receives the H.245 Control Channels from the endpoints. In this manner, the Gatekeeper can route 
the H.245 Control Channels to the MC at the start of the call or when the conference switches to 
multipoint. 

The Gateway can function as a terminal or an MCU. When functioning as a terminal, the Gateway 
may contain an MC. This has the same characteristics as described above for an MC within a 
terminal. 

An MCU always contains an MC. The MCU is callable and the MC processes the H.245 Control 
Channel from all of the endpoints. 

When two or more endpoints are in a conference, the endpoints shall use the master slave resolution 
procedure of Recommendation H.245 to determine the MC that will control the conference. 
After the capability exchange and master/slave determination, the MC may first assign a terminal 
number to a new endpoint using the terminalNumber Assign. The MC shall then notify the other 
endpoints of the new endpoint in the conference using terminalJoinedConference. The new 
endpoint may request a list of other endpoints in the conference using the terminalListRequest. 

6.6 Multipoint processor characteristics 

The MP receives audio, video and/or data streams from the endpoints involved in a centralized or 
hybrid multipoint conference. The MP>ocesses these media streams and returns them to the 
endpoints. 

Communications between the MC and the MP are not subject to standardization. 

The MP may process one or more media stream types. When the MP processes video, it shall 

process the video algorithms and formats as described in 6.2.4. When the MP processes audio, it 
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shall process the audio algorithms as described in 6.2.5. When the MP processes data, it shall 
process data streams as described in 6.2.7. 

An MP which processes video shall provide either video switching or video mixing. Video switching 
is the process of selecting the video that the MP outputs to the terminals from one source to another. 
The criteria used to make the switch may be determined through detection of a change in speaker 
(sensed by the associated audio level) or through H.245 control. Video mixing is the process of 
formatting more than one video source into the video stream that the MP outputs to the terminals. An 
example of video mixing is combining four source pictures into a two-by-two array in the video 
output picture. The criteria for which sources and how many are mixed is determined by the MC 
until other controls are defined. The use of the T.120-Series Recommendations for these control 
functions is for further study. 

An MP which processes audio shall prepare N-audio outputs from M-audio inputs by switching, 
mixing, or a combination of these. Audio mixing requires decoding the input audio to linear signals 
(PCM or analogue), performing a linear combination of the signals and recoding the result to the 
appropriate audio format. The MP may eliminate or attenuate some of the input signals in order to 
reduce noise and other unwanted signals. Each audio output may have a different mix of input 
signals providing for private conversations. The terminals shall assume that their audio is not present 
in the audio stream returned to them. Terminal removal of its own audio from the MP audio output is 
for further study. 

An MP which processes T.120 data shall be capable of acting as a non-leaf MCS provider and 
should be capable of acting as the Top MCS Provider. An MP may also process non-standard data, 
transparent user data and/or other types of data. 

The MP may provide algorithm and format conversion, allowing terminals to participate in a 
conference at different SCMs. 

The MP is not callable, the MCU which it is a part of is callable. The MP terminates and sources the 
media channels. 



6.7 Multipoint control unit characteristics 

The MCU is an endpoint which provides support for multipoint conferences. The MCU shall consist 
of an MC and zero or more MPs. The MCU uses H.245 messages and procedures to implement 
features similar to those found in Recommendation H.243. 

A typical MCU that supports centralized multipoint conferences consists of an MC and an audio, 
video and data MP. A typical MCU that supports decentralized multipoint conferences consists of an 
MC and a data MP supporting Recommendation T.120. It relies on decentralized audio and video 
processing. 

The LAN side of a Gateway may be an MCU. A Gatekeeper may also include an MCU. In either 

case they are independent functions that happen to be co-located. 

The MCU shall be callable by other endpoints using the procedures of clause 8. 

6.8 Multipoint capability 

6.8.1 Centralized multipoint capability 

All terminals shall have centralized multipoint capability. A Gateway which appears as a terminal on 
the LAN shall also have centralized multipoint capability. In this mode of operation they 
communicate with the MC of the MCU in a point-to-point manner on the control channel and with 
the MP on the audio, video and data channels. In this mode, the MC performs H.245 multipoint 
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control functions, while the MP performs video switching or mixing, audio mixing, and T.120 
multipoint data distribution. The MP transmits the resulting video, audio and data streams back to 
the terminals. The MP may have the capability to convert between different audio, video and data 
formats and bit rates, allowing the terminals to participate in the conference using different 
communications modes. 

The MCU may use multicast to distribute the processed video if the terminals in the conference can 
receive multicast transmissions. Multicast distribution of processed audio is for further study. 
This mode is signalled by the following H.245 capabilities: centralizedControI, centralizedAudio, 
centralizedVideo, and centralizedData. 

6.8.2 Decentralized multipoint capability 

If the terminals have decentralized multipoint capability, they communicate with the MC of an 
MCU Gateway, Gatekeeper, or terminal in a point-to-point mode on the H.245 Control Channel and 
optionally with an MP on data channels. The terminals shall have the capability to multicast their 
audio and video channels to all other endpoints in the conference. The MC may control which 
terminal or terminals are actively multicasting audio and/or video (for example by using the 
flowControlCommand on either channel). 

The terminals receive multicast video channels and select one or more of the available channels for 
display to the user. The terminals receive the multicast audio channels and perform an audio mixing 
function in order to present a composite audio signal to the user. 

The MC may provide conference control functions such as chair control, video broadcast and video 
selection This shall be done by receiving H.245 from a terminal and then sending the appropriate 
control to other terminals to enable or disable their video multicast. T.120 commands may optionally 
provide the same functions. 

This mode is signalled by the following H.245 capabilities: centralizedControI, 
decentralized Audio, decentralizedVideo, and centralizedData. 

6.8.3 Hybrid multipoint - Centralized audio 

If the terminals and MCU have hybrid multipoint-centralized audio capability, they may use 
distributed multipoint for video and centralized multipoint for audio. In this mode, the terminals 
communicate with the MC in a point-to-point mode on the H.245 Control Channel and optionally 
with an MP on data channels. 

The terminals shall have the capability to multicast their video channels to all other endpoints in the 
conference. The MC may control which terminal or terminals are actively multicasting video The 
terminals receive multicast video channels and select one or more of the available channels for 
display to the user. 

All of the terminals in the conference transmit their audio channels to the MP. The MP performs the 
audio mixing function and outputs the resulting audio streams to the terminals. The MP may produce 
an exclusive audio sum for each terminal in the conference. Multicast distribution of processed audio 
is for further study. 

This mode is signalled by the* following >*.245 capabilities: centralizedControI, centralizedAudio, 
decentralizedVideo, and centralizedData. 

6.8.4 Hybrid multipoint - Centralized video 

If the terminals and MCU have hybrid multipoint-centralized video capability, they may use 
distributed multipoint for audio and centralized multipoint for video. In this mode, the terminals 
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communicate with the MC in a point-to-point mode on the H.245 Control Channel and optionally 
with an MP on data channels. 

The terminals shall have the capability to multicast their audio channels to all other endpoints in the 
conference. The MC may control which terminal or terminals are actively multicasting audio. The 
terminals receive multicast audio channels and perform a mixing function in order to present a 
composite audio signal to the user. 

All of the terminals in the conference transmit their video channels to the MP. The MP performs the 
video switching, mixing, or format conversion functions and outputs the resulting video streams to 
the terminals. The MP may produce an exclusive video stream for each terminal in the conference, 
or it may multicast a video stream to all participating terminals, in order to minimize the bandwidth 
used on the LAN. 

This mode is signalled by the following H.245 capabilities: centralizedControl, 
decentralizedAudio, centralizedVideo, and centralizedData. 

6.8.5 Establishment of common mode 

The MC shall coordinate a common communications mode between the terminals in the multipoint 
conference. The MC may force terminals into a particular common mode of transmission (as allowed 
by their capability sets) by sending to the terminal a receive capability set listing only the desired 
mode of transmission, or the MC may rely on multipointModeCommand and mode preference 
commands to enforce mode symmetry. The latter approach should be used since it allows the 
terminals to know the full range of conference capabilities available that can be requested. 

If the MCU has the capability to convert audio and/or video formats, it may not be necessary to force 
all terminals into the same communications mode. 

6.8.6 Multipoint rate matching 

Since the terminals on each link in a multipoint configuration may attempt to operate at different bit 
rates, the MC shall send H.245 flowControlCommand messages to limit the transmitted bit rates to 
those which can be sent to receivers. 

6.8.7 Multipoint lip synchronization 

An MP which is providing audio mixing in either the Centralized or Hybrid multipoint conferences 
shall modify the time tags of the audio and video streams, taking into account its own time base, in 
order to maintain audio and video synchronization. Further, when the MP processes the audio and/or 
video to generate a new stream sourced from the MP, the MP shall generate its own sequence 
numbers in the audio and video packets. 

When mixing audio, the MP should synchronize each of the incoming audio streams to its own 
timing, mix the audio streams, and then shall generate a new audio stream based on its own timing 
with its own sequence numbers. If the MP is also switching video, the switched stream shall have its 
original time-stamp replaced with the MP time base to synchronize it with the mixed audio stream 
and shall have a new sequence number representing the stream from the MP. 

In the case of distributed multipoint conferences, the receiving terminal may be able to maintain lip 
synchronization by aligning the selected video stream and its associated audio by using the RTP time 
tags. Alignment of the other audio streams may not be necessary. If multiple video streams are 
displayed, the associated audio streams should be aligned. 

It may not be possible to guarantee lip synchronization in hybrid multipoint conferences. 
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6.8.8 Multipoint encryption 

In a centralized multipoint configuration, the MP is considered to be a trusted entity. Each port of the 
MP decrypts the information streams from each of the H.323 terminals and encrypts the information 
streams to each terminal in accordance with 10.1. Operation of an untrusted MCU is for further 
study. 

Encryption in decentralized and hybrid multipoint conferences is for further study. 

6.8.9 Cascading multipoint control units 

The multipoint control function may be distributed between several MCU entities. Such operations 
are for further study. 



7 Call signalling 

Call signalling is the messages and procedures used to establish a call, request changes in bandwidth 
of the call, get status of the endpoints in the call, and disconnect the call. Call signalling uses 
messages defined in Recommendation H.225.0 and the procedures described in clause 8. This clause 
describes some call signalling concepts. 

7.1 Addresses 

7.1.1 LAN address 

Each H.323 entity shall have at least one LAN Address. This address uniquely identifies the H.323 
entity on the LAN. Some entities may share a LAN Address (i.e. a terminal and a co-located MC). 
This address is specific to the LAN environment in which the endpoint is located. Different LAN 
environments may have different LAN Address formats. 

An endpoint may use different LAN addresses for different channels within the same call. 

7.1.2 TSAP identifier 

For each LAN Address, each H.323 entity may have several TSAP Identifiers. These TSAP 
Identifiers allow multiplexing of several channels sharing the same LAN Address. 
Endpoints have one well-known TSAP Identifier defined: the Call Signalling Channel TSAP 
Identifier. Gatekeepers have one well-known TSAP Identifier defined: the RAS Channel TSAP 
Identifier and one well-known multicast address defined: Discovery Multicast Address. These are 
defined in Appendix IV/H.225.0. 

Endpoints and H.323 entities should use dynamic TSAP Identifiers for the H.245 Control Channel, 
Audio Channels, Video Channels, and Data Channels. The Gatekeeper should use a dynamic TSAP 
Identifier for Call Signalling Channels. The RAS Channels and Signalling Channels may be 
redirected to dynamic TSAP Identifiers during the registration procedure. 

7.1.3 Alias address 

An endpoint may also have one or more alias addresses associated with it. The alias addresses 
provide an alternate method of addressing the endpoint. These address include E.164 addresses 
(network access number, telephone number, etc.), H.323 IDs (name, e-mail like address, etc.), and 
any others defined in Recommendation H.225.0. Alias addresses shall be unique within a Zone. 
Gatekeepers, MCs, and MPs shall not have alias addresses. 

When there is no Gatekeeper in the system, the calling endpoint shall address the called endpoint 
directly using the Call Signalling Channel Transport Address of the called endpoint. When there is a 
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Gatekeeper in the system, the calling endpoint may address the called endpoint by its Call Signalling 
Channel Transport Address, or alias address. The latter shall be translated into a Call Signalling 
Channel Transport Address by the Gatekeeper. 

The called endpoint's E.164 address may consist of an optional access code followed by the E.164 
address. The access code consists of n digits from the set of 0 to 9, *, and #. The number of digits 
and their meaning is left to the discretion of the manufacturer. One purpose of such an access code 
might be to request access to a Gateway. The Gatekeeper may alter this address prior to sending it to 
the destination. 

The H.323 ID consists of a string of ISO/IEC 10646-1 characters as defined in 
Recommendation H.225.0. It may be a user name, e-mail name, or other identifier. 

An endpoint may have more than one alias address (including more than one of the same type) 
which is translated to the same Transport Address. The endpoint's alias addresses shall be unique 
within a Zone. 

7.2 Registration, Admissions and Status (RAS) channel 

The RAS Channel shall be used to carry messages used in the Gatekeeper discovery and endpoint 
registration processes which associate an endpoint's alias address with its Call Signalling Channel 
Transport Address. The RAS Channel shall be an unreliable channel. 

7.2.1 Gatekeeper discovery 

Gatekeeper discovery is the process an endpoint uses to determine which Gatekeeper to register 
with. This may be done manually or automatically. Manual discovery relies on methods outside the 
scope of this Recommendation to determine which Gatekeeper an endpoint is associated with. The 
endpoint is configured with the Transport Address of the associated Gatekeeper. For example, it may 
be entered at endpoint configuration, or it may be entered into an initialization file. In this way, the 
endpoint knows a priori which Gatekeeper it is associated with. The endpoint can now register with 
that Gatekeeper. 

The Automatic method allows the endpoint-Gatekeeper association to change over time. The 
endpoint may not know who its Gatekeeper is, or may need to identify another Gatekeeper due to a 
failure. This may be done through auto discovery. Auto discovery allows for lower administrative 
overhead in configuring individual endpoints and additionally allows replacement of an existing 
Gatekeeper without manually reconfiguring all of the affected endpoints. 

The endpoint may multicast (or use other methods as described in Appendix IV/H.225.0 a 
Gatekeeper Request (GRQ) message, asking "Who is my Gatekeeper?". This is sent to the 
Gatekeeper's well-known Discovery Multicast Address. One or more Gatekeepers may respond with 
the Gatekeeper Confirmation (GCF) message indicating "I can be your Gatekeeper.", and returns the 
Transport Address of the Gatekeeper's RAS Channel. If a Gatekeeper does not want the endpoint to 
register to it, it shall return Gatekeeper Reject (GRJ). See Figure 7. If more than one Gatekeeper 
responds, the endpoint may choose the Gatekeeper it wants to use. At this point, the endpoint knows 
which Gatekeeper to register with. The endpoint can now register with that Gatekeeper. 
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Figure 7/H.323 - Auto Discovery 



If no Gatekeeper responds within a timeout, the endpoint may retry the GRQ. An endpoint shall not 
send a GRQ within 5 s after sending a previous one. If no response is received, the endpoint may use 
the manual discovery method. 

If at any time an endpoint determines it has an invalid registration with its Gatekeeper, it must 
re-discover its Gatekeeper. The invalid registration may be detected by either receiving an RRJ 
message from a Gatekeeper in response to an RRQ from the endpoint, or not receiving any response 
to an RRQ from the endpoint within a time-out. 

The GRQ may be repeated periodically (i.e. at endpoint power-up), so the Gatekeeper shall be able 
to handle multiple requests from the same endpoint. 

7.2.2 Endpoint registration 

Registration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its 
Transport Address and alias addresses. As part of their configuration process, all endpoints shall 
register with the Gatekeeper identified through the discovery process. Registration shall occur before 
any calls are attempted and may occur periodically as necessary (for example, at endpomt power- 
up). 

An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the 
Gatekeeper's RAS Channel Transport Address. The endpoint has the LAN Address of the 
Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP 
Identifier The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a 
Registration Reject (RRJ). See Figure 8. An endpoint shall only register with a single Gatekeeper. 
The RRQ may be repeated periodically (i.e. at terminal power-up), so the Gatekeeper shall be able to 
handle multiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same 
alias address and the same Transport Address as a previous RRQ, it shall respond with RCF. If a 
Gatekeeper receives an RRQ having the same alias address as a previous RRQ and a different 
Transport Address, it should reject the registration indicating a duplicate registration. If the 
Gatekeeper receives an RRQ having the same Transport Address as a previous RRQ and a different 
alias address, it should replace the translation table entries. The Gatekeeper may have a method to 
authenticate these changes which is for further study. 

The Gatekeeper shall ensure that each alias address translates uniquely to a single Transport 
Address. Ambiguous registrations shall be rejected by the Gatekeeper. The Gatekeeper may reject 
the registration for other reasons, such as^changes in discovery or security issues. 
If the endpoint does not include an alias address in the RRQ message, the Gatekeeper may assign 
one. The Gatekeeper shall return the assigned alias address to the terminal in the RCF message. 
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Figure 8/H.323 - Registration 



An endpoint may cancel its registration by sending an Unregister Request (URQ) message to the 
Gatekeeper. The Gatekeeper shall respond with an Unregister Confirmation (UCF) message. This 
allows endpoints to change the alias address associated with its Transport Address, or vice versa. If 
the endpoint was not registered with the Gatekeeper, it shall return an Unregister Reject (URJ) 
message to the endpoint. 

A Gatekeeper may cancel the registration of an endpoint by sending an Unregister Request (URQ) 
message to the endpoint; The endpoint shall respond with an Unregister Confirmation (UCF) 
message. The endpoint shall re-register with a Gatekeeper prior to initiating any calls. This may 
require the endpoint to register with a new Gatekeeper. 

An endpoint which is not registered with a Gatekeeper is called an unregistered endpoint. This type 
of endpoint does not request admission permission from a Gatekeeper and so cannot participate in 
admissions control, bandwidth control, address translation and other functions performed by the 
Gatekeeper. 

7.2.3 Endpoint location 

An endpoint or Gatekeeper which has an alias address for an endpoint and would like to determine 
its Transport Address may issue a Location Request (LRQ) message. This message may be sent to a 
specific Gatekeeper, or may be multicast like the GRQ message. This is sent to the Gatekeeper's 
well-known RAS Channel TS AP Identifier, or if multicast, is sent to the Gatekeeper's well-known 
Discovery Multicast Address. The Gatekeeper with which the requested endpoint is registered, shall 
respond with the Location Confirmation (LCF) message containing the Transport Address of the 
endpoint's Call Signalling Channel or the endpoint's Gatekeeper's Call Signalling Channel. All 
Gatekeepers with which the requested endpoint is not registered, shall return Location Reject (LRJ) 
if they received the LRQ on the RAS Channel. Any Gatekeeper with which the requested endpoint is 
not registered, shall not respond to the LRQ, if it received the LRQ on the Discovery Multicast 
address. 
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7.2.4 Admissions, bandwidth change, status, disengage 

The RAS Channel is also used for the transmission of Admissions, Bandwidth Change, Status, and 
Disengage messages. These messages take place between an endpoint and a Gatekeeper and are used 
to provide admissions control and bandwidth management functions. The detailed use of these 
messages is described in clause 8. 

The Admissions Request (ARQ) message specifies the requested Call Bandwidth. This is an upper 
limit on the aggregate bit rate for all transmitted and received, audio and video channels excluding 
any RTP headers, RTP payload headers, LAN headers, and other overhead. Data and control 
channels are not included in this limit. The Gatekeeper may reduce the requested Call Bandwidth in 
the Admissions Confirm (ACF) message. An endpoint shall assure that the aggregate bit rate, 
averaged over one second, for all transmitted and received, audio and video channels is at or below 
the Call Bandwidth. An endpoint or the Gatekeeper may attempt to modify the Call Bandwidth 
during a call using the Bandwidth Change Request (BRQ) message. 

7.3 Call signalling channel 

The Call Signalling Channel shall be used to carry H.225.0 call control messages. The Call 
Signalling channel shall be a reliable channel. 

In networks that do not contain a Gatekeeper, call signalling messages are passed directly between 
the calling and called endpoints using the Call Signalling Transport Addresses. In these networks, it 
is assumed that the calling endpoint knows the Call Signalling Transport Address of the called 
endpoint and thus can communicate directly. 

In networks that do contain a Gatekeeper, the initial admission message exchange takes place 
between the calling endpoint and the Gatekeeper using the Gatekeeper's RAS Channel Transport. 
Address. Within the initial admissions message exchange, the Gatekeeper indicates in the ACF 
message whether to send the call signalling directly to the other endpoint or to route it through the 
Gatekeeper. The call signalling messages are sent to either the endpoint's Call Signalling Transport 
Address or the Gatekeeper's Call Signalling Transport Address. 

Recommendation H.225.0 specifies the mandatory Q.931 messages that are used for call signalling 
in this Recommendation. Clause 8 specifies the procedures for using them. 

7.3.1 Call signalling channel routing 

Call signalling messages may be passed in two ways. The first method is Gatekeeper Routed Call 
Signalling (see Figure 9). In this method, call signalling messages are routed through the Gatekeeper 
between the endpoints. The second method is Direct Endpoint Call Signalling (see Figure 10). In this 
method, the call signalling messages are passed directly between the endpoints. The choice of which 
methods is used is made by the Gatekeeper. 

Both methods use the same kinds of connections for the same purposes, and the same messages. 
Admissions messages are exchanged on RAS channels with the Gatekeeper, followed by an 
exchange of call signalling messages on a Call Signalling channel. This is then followed by the 
establishment of the H.245 Control Channel. The actions of the Gatekeeper in response to the 
admission messages detennine which callmodel is used this is not under the control of the endpoint, 
although the endpoint can specify a preference. 

For the Gatekeeper Routed method, the Gatekeeper may choose to close the Call Signalling Channel 
after the call set-up is completed, or it may choose to keep it open for the duration of the call to 
support supplementary services. Only the Gatekeeper shall close the Call Signalling Channel and it 
should not be closed when a Gateway is involved in the call. 
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The symmetrical signalling method of Annex D/Q.93 1 shall be used for all mandatory call signalling 
procedures. This does not address the role that a Gateway might play on the SCN side using Q.931 
or other call signalling protocols. 

The Gatekeeper Clouds in Figures 9 through 12 contain one or more Gatekeepers which may or may 
not communicate with each other. The endpoints may be connected to the same Gatekeeper or to 
different Gatekeepers. 
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Figure 9/H.323 - Gatekeeper routed call signalling 
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Figure 10/H.323 - Direct endpoint call signalling 



7.3.2 Control channel routing 

When Gatekeeper Routed call signalling is used, there are two methods to route the H.245 Control 
Channel. In the first method, the H.245 Control Channel is established directly between the 
endpoints. See Figure 1 1. This method is for further study. In the second method, the H.245 Control 
Channel is routed between the endpoints through the Gatekeeper. See Figure 12. This method allows 
the Gatekeeper to redirect the H.245 Control Channel to an MC when an ad hoc multipoint 
conference switches from a point-to-point conference to a multipoint conference. This choice is 
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made by the Gatekeeper. When Direct Endpoint call signalling is used, the H.245 Control Channel 
can only be connected directly between the endpoints. 
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Figure 11/H.323 - Direct H.245 control channel connection between endpoints 
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Figure 12/H.323 - Gatekeeper routed H.245 control 



7.4 Call reference value 

All call signalling and RAS messages contain a Call Reference Value (CRV). Refer to 
Recommendation H.225.0. This is used to associate all messages related to the same call. The same 
CRV shall be used in all admissions, cair*et-up, supplementary service, bandwidth change, and call 
termination messages relating to the same call. A new CRV shall be used for new calls. A second 
call from an endpoint to invite another endpoint into the same conference shall use a new CRV. The 
CRV is not the same as the Conference ID (CID). The CRV relates messages within the same call, 
the CID relates calls within the same conference. 
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7.5 Conference ID and Conference Goal 

The Conference ID (CID) is a unique non-zero value created by the originating endpoint and passed 
in various H.225.0 messages, encoded with CID octet zero first. The CID identifies the conference 
with which the message is associated. The CID shall be formed from 16 octets as follows: 
CID octet 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Value N5 N4 N3 N2 Nl NO CI CO HI AV Ml MO L3 L2 LI LO 

where an index of 0 (e.g. NO) refers to the lowest order octet of the respective value (e.g. N5:N0): 
N5:0 is 48 bits of physical LAN address, if available. 

C1:0 is 16 bits of counter incremented per conference if the clock cannot be guaranteed to be 
monotonic. 

HI, A, M1:0, L3:0 is low order 60 bits of 100 nanosecond clock since October 15, 1582 local 
timezone. The assignment of bits is as follows: 



HI 
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MO 


L3 


L2 


LI 


LO 


59 52 


51 48 


47 


32 


31 






0 



V is 4 bits of version number = 0001 placed in the lower order 4 bits of CID octet 6. 

The conferenceGoal indicates the intention of the call. Choices are: 

Create - To create a new conference; 

Join - To join an existing conference; and 

Invite - To invite a new endpoint into an existing conference. 



8 Call signalling procedures 

The provision of the communication is made in the following steps: 
Phase A: Call set-up (see 8. 1). 

Phase B: Initial communication and capability exchange (see 8.2). 
Phase C: Establishment of audiovisual communication (see 8.3). 
Phase D: Call Services (see 8.4). 
Phase E: Call termination (see 8.5). 



8.1 Phase A - Call set-up 

Call set-up takes place using the call control messages defined in Recommendation H.225.0 
according to the call control procedures defined below. Requests for bandwidth reservation should 
take place at the earliest possible phase. 

If both the alias address and the transport address are specified, preference shall be given to the alias 
address. 

8.1.1 Basic call set-up - Neither endpoint registered 

In the scenario shown in Figure 13 neither endpoint is registered to a Gatekeeper. The two endpoints 
communicate directly. Endpoint 1 (calling endpoint) sends the Set-up (1) message to the well-known 
Call Signalling Channel TSAP Identifier of endpoint 2. Endpoint 2 responds with the Connect (4) 
message which contains an H.245 Control Channel Transport Address for use in H.245 signalling. 



Recommendation H.323 (1 1/96) 



Superseded by a more recent version 



37 



seded by a more recentj 

Endpoint I Endpoint 2 



on 



Set-uDfl) 




Call proceeding (2) 


> 


< — 


Alerting (3) 




< — 


Connect (4) 




< : 



T1 527150-97 



Call Signalling Messages 

Figure 13/H.323 - Basic call set-up, no Gatekeepers 



8,1.2 Both endpoints registered to the same Gatekeeper 

In the scenario shown in Figure 14, both endpoints are registered to the same Gatekeeper, and the 
Gatekeeper has chosen Direct Call Signalling. Endpoint 1 (calling endpoint) initiates the 
ARQ (1)/ACF (2) exchange with that Gatekeeper. The Gatekeeper shall return the Call Signalling 
Channel Transport Address of endpoint 2 (called endpoint) in the ACF. Endpoint 1 then sends the 
Set-up (3) message to endpoint 2 using that Transport Address. If endpoint 2 wishes to accept the 
call it initiates an ARQ (5)/ACF (6) exchange with the Gatekeeper. It is possible that an ARJ (6) is 
received by endpoint 2, in which case it sends Release Complete to endpoint 1. Endpoint 2 responds 
with the Connect (4) message which contains an H.245 Control Channel Transport Address for use 
in H.245 signalling. 
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Figure 14/H.323 - Both endpoints registered, same Gatekeeper - Direct call signalling 
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In the scenario shown in Figure 15, both endpoints are registered to the same Gatekeeper, and the 
Gatekeeper has chosen to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ 
(1)/ACF (2) exchange with that Gatekeeper. The Gatekeeper shall return a Call Signalling Channel 
Transport Address of itself in the ACF. Endpoint 1 then sends the Set-up (3) message using that 
Transport Address. The Gatekeeper then sends the Set-up (4) message to endpoint 2. If endpoint 2 
wishes to accept the call, it initiates an ARQ (6)/ACF (7) exchange with the Gatekeeper. It is 
possible that an ARJ (7) is received by endpoint 2, in which case it sends Release Complete to the 
Gatekeeper. Endpoint 2 responds with the Connect (9) message which contains an H.245 Control 
Channel Transport Address for use in H.245 signalling. The Gatekeeper sends the Connect (10) 
message to endpoint 1 which may contain the endpoint 2 H.245 Control Channel Transport Address, 
or a Gatekeeper (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 
chooses to route the H.245 Control Channel or not. 
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Figure 15/H.323 - Both endpoints registered, same Gatekeeper - 
Gatekeeper routed call signalling 



8.1.3 Only calling endpoint has Gatekeeper 

In the scenario shown in Figure 16, endpoint 1 (calling endpoint) is registered with a Gatekeeper, 
endpoint 2 (called endpoint) is not registered with a Gatekeeper, and the Gatekeeper has chosen 
Direct Call Signalling. Endpoint 1 initiates the ARQ (1)/ACF (2) exchange with the Gatekeeper. 
Endpoint 1 then sends the Set-up (3) message to endpoint 2 using the well-known Call Signalling 
Channel Transport Address. If endpoint 2 wishes to accept the call, it responds with the Connect (4) 
message which contains an H.245 Control Channel Transport Address for use in H.245 signalling. 
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Figure 16/H.323 - Only calling endpoint registered - Direct call signalling 

In the scenario shown in Figure 17, endpoint 1 (calling endpoint) is registered with a Gatekeeper, 
endpoint 2 (called endpoint) is not registered with a Gatekeeper, and the Gatekeeper has chosen to 
route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange with 
that Gatekeeper. The Gatekeeper shall return a Call Signalling Channel Transport Address of itself 
in the ACF (2). Endpoint 1 then sends the Set-up (3) message using that Transport Address. The 
Gatekeeper then sends the Set-up (4) message to the well-known Call Signalling Channel Transport 
Address of endpoint 2. If endpoint 2 wishes to accept the call, it responds with the Connect (7) 
message which contains an H.245 Control Channel Transport Address for use in H.245 signalling. 
The Gatekeeper sends the Connect (9) message to endpoint 1 which may contain the endpoint 2 
H.245 Control Channel Transport Address, or a Gatekeeper (MC) H.245 Control Channel Transport 
Address, based on whether the Gatekeeper chooses to route the H.245 Control Channel or not. 
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Figure 17/H.323 - Only calling endpoint registered - Gatekeeper 
routed call signalling 
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8.1.4 Only called endpoint has Gatekeeper 

In the scenario shown in Figure 18, endpoint 1 (calling endpoint) is not registered with a Gatekeeper, 
endpoint 2 (called endpoint) is registered with a Gatekeeper, and the Gatekeeper has chosen Direct 
Call Signalling. Endpoint 1 sends the Set-up (1) message to endpoint 2 using the well-known Call 
Signalling Channel Transport Address. If endpoint 2 wishes to accept the call, it initiates an 
ARQ (3)/ACF (4) exchange with the Gatekeeper. It is possible that an ARJ (4) is received by 
endpoint 2, in which case it sends Release Complete to endpoint 1. Endpoint 2 responds with the 
Connect (6) message which contains an H.245 Control Channel Transport Address for use in H.245 
signalling. 
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Figure 18/H.323 - Only called endpoint registered - Direct call signalling 



In the scenario shown in Figure 19, endpoint 1 (calling endpoint) is not registered with a Gatekeeper, 
endpoint 2 (called endpoint) is registered with a Gatekeeper, and the Gatekeeper has chosen to route 
the call signalling. Endpoint 1 (calling endpoint) sends a Set-up (1) message to the well-known Call 
Signalling Channel Transport address of endpoint 2. If endpoint 2 wishes to accept the call, it 
initiates the ARQ (3)/ACF (4) exchange with that Gatekeeper. If acceptable, the Gatekeeper shall 
return a Call Signalling Channel Transport Address of itself in the ARJ (4) with a cause code of 
routeCallToGatekeeper. Endpoint 2 replies to endpoint 1 with a Facility (5) message containing 
the Call Signalling Transport Address of its Gatekeeper. Endpoint 1 then sends the Release 
Complete (6) message to endpoint 2. Endpoint 1 sends a Set-up (7) message to the Gatekeeper's Call 
Signalling Channel Transport Address. The Gatekeeper sends the Set-up (8) message to endpoint 2. 
Endpoint 2 initiates the ARQ (9)/ACF (10) exchange with that Gatekeeper. Endpoint 2 then 
responds with the Connect (12) message which contains its H.245 Control Channel Transport 
Address for use in H.245 signalling, the Gatekeeper sends the Connect (13) message to endpoint 1 
which may contain the endpoint 2 H.245 Control Channel Transport Address, or a Gatekeeper (MC) 
H.245 Control Channel Transport Address, based on whether the Gatekeeper chooses to route the 
H.245 Control Channel or not. 
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Figure 19/H.323 - Only called endpoint registered - Gatekeeper 
routed call signalling 



8.1.5 Both endpoints registered to different Gatekeepers 

In the scenario shown in Figure 20, both endpoints are registered to different Gatekeepers, and both 
Gatekeepers choose Direct Call Signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF 
(2) exchange with Gatekeeper 1. Gatekeeper 1 may return the Call Signalling Channel Transport 
Address of endpoint 2 (called endpoint) in the ACF if Gatekeeper 1 has a method of communicating 
with Gatekeeper 2. Endpoint 1 then sends the Set-up (3) message to either the Transport Address 
returned by the Gatekeeper (if available) or to the well-known Call Signalling Channel Transport 
Address of endpoint 2. If endpoint 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6) 
exchange with Gatekeeper 2. It is possible that an ARJ (6) is received by endpoint 2, in which case it 
sends Release Complete to endpoint 1. Endpoint 2 responds with the Connect (8) message which 
contains an H.245 Control Channel Transport Address for use in H.245 signalling. 
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Figure 20/H.323 - Both endpoints registered - Both gatekeepers 
direct call signalling 



In the scenario shown in Figure 21, both endpoints are registered to different Gatekeepers, the 
calling endpoint's Gatekeeper chooses Direct Call. Signalling, and the called endpoint's Gatekeeper 
chooses to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) • 
exchange with Gatekeeper 1. Gatekeeper 1 may return the Call Signalling Channel Transport 
Address of endpoint 2 (called endpoint) in the ACF (2) if Gatekeeper 1 has a method of 
communicating with Gatekeeper 2. Endpoint 1 then sends the Set-up (3) message to either the 
Transport Address returned by the Gatekeeper (if available) or to the well-known Call Signalling 
Channel Transport Address of endpoint 2. If endpoint 2 wishes to accept the call, it initiates the 
ARQ (5)/ACF (6) exchange with Gatekeeper 2. If acceptable, Gatekeeper 2 shall return a Call 
Signalling Channel Transport Address of itself in the ARJ (6) with a cause code of 
routeCaUToGatekeeper. Endpoint 2 replies to endpoint 1 with a Facility (7) message containing 
the Call Signalling Transport Address of Gatekeeper 2. Endpoint 1 then sends the Release Complete 
(8) message to endpoint 2. Endpoint 1 shall send a DRQ (9) to Gatekeeper 1 which responds with 
DCF (10). Endpoint 1 then initiates a new ARQ(11)/ACF (12) exchange with Gatekeeper 1. 
Endpoint 1 sends a Set-up (13) message to the Gatekeeper's Call Signalling Channel Transport 
Address. Gatekeeper 2 sends the Set-up (14) message to endpoint 2. Endpoint 2 initiates the ARQ 
(15)/ACF (16) exchange with Gatekeeper 2. Endpoint 2 then responds with the Connect (18) 
message which contains its H.245 Control Channel Transport Address for use in H.245 signalling. 
Gatekeeper 2 sends the Connect (19) message to endpoint 1 which may contain the endpoint 2 H.245 
Control Channel Transport Address, or a Gatekeeper 2 (MC) H.245 Control Channel Transport 
Address, based on whether the Gatekeeper chooses to route the H.245 Control Channel or not. 
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Figure 21/H.323 - Both endpoint registered - Direct/routed call signalling 



In the scenario shown in Figure 22, both endpoints are registered to different Gatekeepers, the 
calling endpoint's Gatekeeper chooses to route the call signalling, and the called endpoint's 
Gatekeeper chooses Direct Call Signalling. Endpoint 1 (calling endpoint) initiates the 
ARQ (1)/ACF (2) exchange with Gatekeeper 1. Gatekeeper 1 shall return a Call Signalling Channel 
Transport Address of itself in the ACF (2). Endpoint 1 then sends the Set-up (3) message using that 
Transport Address. Gatekeeper 1 then sends the Set-up (4) message containing its Call Signalling 
Channel Transport AddressAo the w%known Call Signalling Channel Transport Address of 
endpoint 2. If endpoint 2 wishes to accept the call, it initiates the ARQ (6)/ACF (7) exchange with 
Gatekeeper 2. It is possible that an ARJ (7) is received by endpoint 2, in which case it sends Release 
Complete to endpoint 1. Endpoint 2 responds to Gatekeeper 1 with the Connect (9) message which 
contains its H.245 Control Channel Transport Address for use in H.245 signalling. Gatekeeper 1 
sends the Connect (10) message to endpoint 1 which may contain the endpoint 2 H.245 Control 
Channel Transport Address, or a Gatekeeper 1 (MC) H.245 Control Channel Transport Address, 
based on whether the Gatekeeper chooses to route the H.245 Control Channel or not. 
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Figure 22/H.323 - Both endpoint registered - Routed/direct call signalling 



In the scenario shown in Figure 23, both endpoints are registered to different Gatekeepers, and both 
Gatekeepers choose to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ 
(1)/ACF (2) exchange with Gatekeeper. 1. Gatekeeper 1 shall return a Call Signalling Channel 
Transport Address of itself in the ACF (2). Endpoint 1 then sends the Set-up (3) message using that 
Transport Address. Gatekeeper 1 then sends the Set-up (4) message to the well-known Call 
Signalling Channel Transport Address of endpoint 2. If endpoint 2 wishes to accept the call, it 
initiates the ARQ (6)/ ACF (7) exchange with Gatekeeper 2. If acceptable, Gatekeeper 2 shall return 
a Call Signalling Channel Transport Address of itself in the ARJ (7) with a cause code of 
routeCallToGatekeeper. Endpoint 2 replies to Gatekeeper 1 with a Facility (8) message containing 
the Call Signalling Transport Address of Gatekeeper 2. Gatekeeper 1 then sends the Release 
Complete (9) message to endpoint 2. Gatekeeper 1 sends a Set-up (10) message to Gatekeeper 2's 
Call Signalling Channel Transport Address. Gatekeeper 2 sends the Set-up (1 1) message to endpoint 
2. Endpoint 2 initiates the ARQ (12)/ACF (13) exchange with Gatekeeper 2. Endpoint 2 then 
responds to Gatekeeper 2 with the Connect (15) message which contains its H.245 Control Channel 
Transport Address for use in H.245 signalling. Gatekeeper 2 sends the Connect (16) message to 
Gatekeeper 1 which may contain the endpoint 2 H.245 Control Channel Transport Address, or a 
Gatekeeper 2 (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 2 
chooses to route the H.245 Control Channel or not. Gatekeeper 1 sends the Connect (17) message to 
endpoint 1 which may contain the H.245 Control Channel Transport Address sent by Gatekeeper 2, 
or a Gatekeeper 1 (MC) H.245 Control Channel Transport Address, based on whether the 
Gatekeeper 1 chooses to route the H.245 Control Channel or not. 
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Figure 23/H.323 - Both endpoint registered - Both Gatekeepers 
routing call signalling 



8.1.6 Call set-up via gateways 
8.1.6.1 Gateway inbound call set-up 

When an external terminal calls a LAN endpoint via the Gateway, call set-up between the Gateway 
and the LAN endpoint proceeds the same as the endpoint-to-endpoint call set-up. The Gateway may 
need to issue Call Proceeding messages to the external terminal while establishing the call on the 
network. 

A Gateway which cannot directly route an incoming SCN call to an H.323 endpoint shall be able to 
accept two-stage dialling. For, Gateways to H.320 networks (also H.321, H.322 and H.310 in H.321 
mode) the Gateway shall accept SBE numbers from the H.320 terminal. For Gateways to H.310 
native 'mode and H.324 networks, the Gateway shall accept H.245 userlnputlndication messages 
from the H.324 terminal. In these two cases, support of DTMF is optional. For Gateways to speech 
only terminals, the Gateway shall accept DTMF numbers from the speech only terminal. These 
numbers will indicate a second stage dialling number to access the individual endpoint on the LAN. 
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8. 1 .6.2 Gateway outbound call set-up 

When a LAN endpoint calls an external terminal via the Gateway, call set-up between the LAN 
endpoint and the Gateway proceeds the same as the endpoint-to-endpoint call set-up. The Gateway 
will receive the destination E.164 address in the Set-up message. It will then use this address to place 
the outbound call. The Gateway may issue Call Proceeding messages to the LAN endpoint while 
establishing the outgoing call. 

The Progress Indicator information element is used to indicate that inter-networking is occurring. 
The Gateway shall issue a Progress indicator information element within the Alerting, Call 
Proceeding or Connect messages. This information may also be sent in a Progress message. 

The LAN endpoint shall send all E.164 addresses that it is calling in the Set-up message. For 
example, a six B-channel call on the ISDN will require six E.164 addresses in the Set-up message. 
The Gateway shall respond to the Set-up message with a Connect or Release Complete message as 
well as Alerting, Call Proceeding, or Progress messages. Failure of the SCN call shall be reported to 
the LAN endpoint in the Release Complete message. The use of multiple CRV values and multiple 
Set-up messages is for further study. Addition of channels on the SCN during a call is for further 
study. 

A LAN endpoint which is registered with a Gatekeeper should request sufficient call bandwidth in 
the ARQ message for the aggregate of all SCN calls. If sufficient call bandwidth was not requested 
in the ARQ message, the procedures of 8.4.1, Bandwidth Changes, shall be followed in order to 
obtain additional call bandwidth. 

The Gateway may advance to Phase B after placing the first call on the SCN. Additional calls for the 
additional SCN E.164 numbers may be placed after the capability exchange with the Gateway and 
establishment of audio communications with the SCN endpoint. 

8.1.7 Call set-up with an MCU 

For Centralized Multipoint Conferences, all endpoints exchange call signalling with the MCU. Call 
set-up between an endpoint and the MCU proceeds the same as the endpoint-to-endpoint call set-up 
scenarios of 8.1.1 through 8.1.5. The MCU may be the called endpoint or the calling endpoint. 

In a Centralized Multipoint Conference, the H.245 Control Channel is opened between the endpoints 
and the MC within the MCU. The audio, video, and data channels are opened between the endpoints 
and the MP within the MCU. In a Decentralized Multipoint Conference, the H.245 Control Channel 
is open between the endpoint and the MC (there may be many such H.245 Control Channels, one for 
each call). The Audio and Video Channels should be multicast to all endpoints in the conference. 
The Data Channel shall be opened with the Data MP. 

In an ad hoc Multipoint Conference where there is no MC within the endpoints, the H.245 Control 
Channel shall be routed through the Gatekeeper. Initially, the H.245 Control Channel will be routed 
between the endpoints through the Gatekeeper, When the conference switches to multipoint, the 
Gatekeeper may connect the endpoints to an MC associated with the Gatekeeper. 

In an ad hoc Multipoint Conference where one or both of the endpoints contains an MC, the normal 
call set-up procedures defined in 8.1.1 through 8.1.5 are used. The master-slave determination 
procedure is used to determine which MC will be the active MC for the conference. 

8.1.8 Call forwarding 

An endpoint wishing to forward a call to another endpoint may issue a Facility message indicating 
the address of the new endpoint. The endpoint receiving this Facility indication should send a 
Release Complete and then restart the Phase A procedures with the new endpoint. 
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8.1.9 Broadcast call set-up 

This subclause is for further study. 

8.2 Phase B - Initial communication and capability exchange 

Once both sides have exchanged call set-up messages from Phase A, the endpoints shall establish the 
H.245 Control Channel. The procedures of Recommendation H.245 are used over the H.245 Control 
Channel for the capability exchange and to open the media channels. 

NOTE - Optionally, the H.245 Control Channel may be set up by the called endpoint on receipt of Set-up, 
and by calling endpoint on receipt of Alerting or Call Proceeding. In the event that Connect does not arrive, or 
an endpoint sends Release Complete, the H.245 Control Channel shall be closed. 

Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet 

message. This capability message shall be the first H.245 message sent. 

The master-slave determination procedure of H.245 shall take place as described in 6.2.8.4. In cases 
where both endpoints in a call have MC capability, the master-slave determination is used for 
determining which MC will be the active MC for the conference. The active MC may then send the 
mcLocationlndication message. The procedure also provides master-slave determination for 
opening bidirectional channels for data. 

If the initial capability exchange or master-slave determination procedures fail, these should be 
retried at least two additional times before the terminal abandons the connection attempt and 
proceeds to Phase E. 

Following this exchange of capabilities, the endpoints shall proceed directly to the desired operating 
mode, i.e. Phase C. 

8.3 Phase C - Establishment of audiovisual communication 

Following the exchange of capabilities and master-slave determination, the procedures of- 
Recommendation H.245 shall then be used to open logical channels for the various information 
streams. The audio and video streams, which are transmitted in the logical channels set-up in H.245, 
are transported over dynamic TSAP Identifiers using an unreliable protocol (see 
Recommendation H.225.0). Data communications which is transmitted in the logical channels set-up 
in H.245, are transported using a reliable protocol (see Recommendation H.225.0). 
The openLogicalChannelAck returns the Transport Address that the receiving endpoint has 
assigned to that logical channel. The transmitting channel shall then send the information stream 
associated with the logical channel to that Transport Address. 

Following the opening of logical channels for audio and video, one 
h2250MaximumSkewIndication message shall be sent by the transmitter for each associated audio 
and video pair. 

8.3.1 Mode changes 

During a session, the procedures for changing channel structure, capability, receive mode etc. shall 
be carried out as defined in Recommenddtion H.245. 



8.3.2 Exchange of video by mutual agreement 

The indication videoIndicateReadyToActivate is defined in Recommendation H.245. Its use is 
optional, but when used the procedure shall be as follows. 

Endpoint 1 has been set so that video is not transmitted unless, and until, endpoint 2 has also 
indicated readiness to transmit video. Endpoint 1 shall send the indication 
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videoIndicateReadyToActivate when the initial capability exchange has been completed, but shall 
not transmit a video signal until it has received either videoIndicateReadyToActivate or incoming 
video from endpoint 2. 

An endpoint which has not been set in this optional way is not obliged to wait until receipt of 
videoIndicateReadyToActivate or video before initiating its video transmission. 

8.3.3 Media Stream Address Distribution 

In unicast, the endpoint shall open logical channels to the MCU or other endpoint. Addresses are 
passed in the openLogicalChannel and openLogicalChannelAck. 

In multicast, the multicast addresses are assigned by the MC and distributed to the endpoints in the 
communicationsModeCommand. It is the responsibility of the MC to allocate and assign unique 
multicast addresses. The endpoint shall signal an open logical channel to the MC with a multicast 
address in the openLogicalChannel. The MC shall forward the openLogicalChannel to each 
receiving endpoint. 

In multi-unicast, the endpoint must open logical channels to each of the other endpoints. The 
openLogicalChannel is sent to the MC and shall contain the terminal number of the endpoint for 
which the channel is intended. The endpoint can match a openLogicalChannelAck by the 
forwardLogicalChannelNumber. 

8.4 Phase D - Call services 
8.4.1 Bandwidth changes 

Call bandwidth is initially established and approved by the Gatekeeper during the admissions 
exchange. An endpoint shall assure that the aggregate for all transmitted and received audio and 
video channels, excluding any RTP headers, RTP payload headers, LAN headers, and other 
overhead, is within this bandwidth. Data and control channels are not included in this limit. 

At any time during a conference, the endpoints or Gatekeeper may request an increase or decrease in 
the call bandwidth. An endpoint may change the bit rate of a logical channel without requesting a 
bandwidth change from the Gatekeeper if the aggregate bit rate of all transmitted and received 
channels does not exceed the current call bandwidth. If the change will result in a aggregate bit rate 
that exceeds the current call bandwidth, the endpoint shall request a change in the call bandwidth 
from its Gatekeeper and await confirmation prior to actually increasing any bit rate. A bandwidth 
change request is recommended when an endpoint will use a reduced bandwidth for an extended 
period of time, thus freeing up bandwidth for other calls. 

An endpoint wishing to change its call bandwidth sends a Bandwidth Change Request (BRQ) 
message (1) to the Gatekeeper. The Gatekeeper determines if the request is acceptable. The criteria 
for this determination is outside the scope of this Recommendation. If the Gatekeeper determines 
that the request is not acceptable, it returns a Bandwidth Change Reject (BRJ) message (2) to 
endpoint. If the Gatekeeper determines that the request is acceptable, it returns a Bandwidth Change 
Confirm (BCF) message (2). 

If endpoint 1 wishes to increase its transmitted bit rate on a logical channel, it first determines if the 
call bandwidth will be exceeded. See Figure 24. If it will, endpoint 1 shall request a bandwidth 
change (1 and 2) from Gatekeeper 1. When the call bandwidth is sufficient to support the change, 
endpoint 1 sends a closeLogicalChannel (3) message to close the logical channel. It then reopens 
the logical channel using the openLogicalChannel (4) specifying the new bit rate. If the receiving 
endpoint wishes to accept the channel with the new bit rate, it must first assure that its call 
bandwidth is not exceeded by the change. If it is, the endpoint shall request a call bandwidth change 
(5 and 6) with its Gatekeeper. When the call bandwidth is sufficient to support the channel, the 
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endpoint replies with an openLogicalChannelAck (7), otherwise, it responds with an 
openLogicalChannelReject indicating unacceptable bit rate. 
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NOTE - Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper. 

Figure 24/H.323 - Bandwidth change request - Transmitter change 



If the endpoint 1 wishes to increase its transmitted bit rate on a logical channel from endpoint 2, 
which it previously flow controlled to a lower bit rate, endpoint 1 first determines if the call 
bandwidth will be exceeded. See Figure 25. If it will, endpoint 1 shall request a bandwidth change 
from Gatekeeper 1. When the call bandwidth is sufficient to support the change, endpoint 1 sends a 
flowControlCommand (3) to indicate the new upper limit on bit rate for the channel. If endpoint 2 
decides to increase the bit rate on the channel, it must first assure that its call bandwidth is not 
exceeded by the change. If it is, endpoint 2 shall request a call bandwidth change (4 and 5) with its 
Gatekeeper When the call bandwidth is sufficient to support the channel, endpoint 2 will send the 
CloseLogicalChannel (6) message to close the logical channel. It then reopens the logical channel 
using the OpenLogicalChannel (7) specifying the new bit rate. Endpoint 1 should then accept the 
channel with the new bit rate, and it replies with an openLogicalChannelAck (6). 
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NOTE - Gatekeeper l and Gatekeeper 2 may be the same Gatekeeper. 

Figure 25/H.323 - Bandwidth change request - Receiver change 

A Gatekeeper wishing to change the transmitted bit rate of endpoint 1 sends a BRQ message to 
endpoint 1. If the request is for a decrease in bit rate, endpoint 1 shall always comply by reducing its 
aggregate bit rate and returning a BCF. Endpoint 1 may initiate the appropriate H.245 signalling to 
inform endpoint 2 that bit rates have changed. This will allow endpoint 2 to inform its Gatekeeper of 
the change. If the request is for an increase, the endpoint may increase its bit rate when desired. 

8.4.2 Status 

In order for the Gatekeeper to determine if an endpoint is turned off, or has otherwise entered a 
failure mode, the Gatekeeper may use the Information Request (IRQ)/Information Request Response 
(IRR) message sequence (see Recommendation H.225.0) to poll the endpoints at an interval decided 
by the manufacturer. The polling interval shall be greater than 10 s. This message may also be used 
by a diagnostic device as described in 1 1 .2. 

The Gatekeeper may want an endpoint to periodically send an unrequested IRR message. The 
Gatekeeper may indicate this to the endpoint by specifying the rate that this IRR is sent within the 
irrFrequency field of the Admission Confirm (ACF) message. An endpoint receiving this 
irrFrequency rate shall send an IRR message at that rate for the duration of the call. While this rate is 
in effect, the Gatekeeper may still send IRQ messages to the endpoint which shall respond as 
described above. 

During the duration of a call, an endpoint or Gatekeeper may periodically request call status from 
another endpoint. The requesting endpoint or Gatekeeper issues a Status Enquiry message. The 
Endpoint receiving the Status Enquiry message shall respond with a Status message indicating the 
current call state. This procedure may be used by the Gatekeeper in order to periodically check if a 
call is still active. Note that this is a H.225.0 message sent on the Call Signalling Channel, and 
should not be confused with IRR which is a RAS message sent on the RAS Channel. 

8.4.3 Ad Hoc Conference Expansion 

The following procedures are optional for terminals and Gateways and mandatory for MCs. 

An Ad Hoc Multipoint conference is one that can be expanded from a point-to-point conference 
involving an MC to a multipoint conference. First, a point-to-point conference is created between 
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two endpoints (endpoint 1 and endpoint 2). At least one endpoint, or the Gatekeeper, must contain an 
MC Once the point-to-point conference has been created, the conference may be expanded to 
multipoint conference in two different ways. The first way is when any endpoint m the conference 
invites another endpoint (endpoint 3) into the conference by calling that endpoint through the MC. 
The second way is for an endpoint (endpoint 3) to join an existing conference by calling an endpoint 
in the conference. 

Ad Hoc Conference expansion can take place when using either the Direct Call Signalling model or 
the Gatekeeper Routed Call Signalling model. The H.245 Control Channel topology for the Direct 
Call Signalling model appears as: 



Endpoint 1 




MC 




Endpoint 3 




Endpoint 2 
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The H.245 Control Channel topology for the Gatekeeper Routed Call Signalling model appears as: 



Endpoint 1 




MC 




Endpoint 3 




Gatekeeper 
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Endpoint 2 





In either case an MC must be present in the conference at the time of expansion to any number 
greater than 2 endpoints. 

The procedures required to create a point-to-point conference and then expand the conference 

through invite and join, for each call model, is covered in the following subclauses. 

It should be noted that the call is ended by a failure of the entity that is providing the MC. 

8.4.3.1 Direct Endpoint Call Signalling - Conference Create 

Endpoint 1 creates a conference with endpoint 2 as follows: 

Al) Endpoint 1 sends a Set-up message to endpoint 2 containing a globally unique CID = N and 

conferenceGoal = create according to the procedure in 8. 1 . 
A2) Endpoint 2 has the following options: 

A2a) If it wants to join the conference, it sends a Connect message with CID = N to 
endpoint 1. In this case it is either: 

1) not participating in another conference; or 

2) it is participating in another conference, it is capable of participating in multiple 
conferences at the same time, and the received CID = N does not match the CID 
of any of the conferences in which it is currently participating. 

A2b) If it is in another conference with CID = M and can participate in only one 
conference at a time it eimer: 

1) rejects the call by sending Release Complete indicating in-conference; or 

2) it can request endpoint 1 to join the conference with CID = M by sending a 
Facility message indicating routeCaUToMC with the Call Signalling Channel 
Transport Address of the endpoint containing the MC and CID - M of the 
conference. 
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A2c) If it does not wish to join this conference, it rejects the call by sending Release 
Complete indicating destinationBusy. 
A3) If endpoint 2 enters the conference, endpoint 1 uses the transport address of the Control 
Channel provided in the Connect message to open the Control Channel with endpoint 2. 

A4) The H.245 messages are then exchanged as described below: 

A4a) TerminalCapabilitySet messages are exchanged between the endpoints to 

determine the version number of the H.245 used in order to parse the remaining 
received messages correctly. 
A4b) Using H.245 master-slave determination procedure, it is determined that endpoint 2 
is the master. In the Gatekeeper-Routed model, the master could be in the 
Gatekeeper's MC. If the master has an MC, it becomes the Active MC. It may then 
send the MCLocationlndication to the other endpoint(s). The MC may be active in 
the conference now, or when the user initiates the multipoint conference function, at 
the choice of the manufacturer. 
A4c) The master may send the terminalNumberAssign message to the endpoints. The 
endpoints shall use the 8-bit terminal number, and not use the 8-bit MCU number, 
from the 16-bit number assigned as the low 8 bits of the SSRC field in the RTP 
header. These low 8 bits in SSRC then identify the streams from a particular 
endpoint. 

A4d) Since the capabilities of the receiver are known from the TerminalCapabilitySet 
message, the transmitter opens the logical channels. It shall send one 
h2250MaximumSkewIndication for each pair of audio and video transmitted. 

8.4.3.2 Direct Endpoint Call Signalling - Conference Invite 

There are two cases of the conference invite. First, the endpoint which contains the active MC 
wishes to invite another endpoint into the conference. Second, an endpoint which does not contain 
the active MC wishes to invite another endpoint into the conference. 

After a point-to-point conference has been established using procedures Al to A4, an endpoint 
(endpoint 2) containing the active MC wishing to add another endpoint to the conference shall use 
the following procedure: 

Bl) Endpoint 2 sends a Set-up message to endpoint 3 with CID = N and conferenceGoal = invite 

according to the procedures in 8.1. See Figure 26. 
B2) Endpoint 3 has the following options: 

B2a) If it wishes to accept the invitation to join the conference, it sends a Connect 

message with CID = N to endpoint 2. 
B2b) If it wishes to reject the invitation to join the conference, it sends a Release 

Complete message indicating destinationBusy to endpoint 2. 
B2c) If it is in another conference with CID = M, it can request endpoint 2 to join the 

conference with CID = M by sending a Facility message indicating 

routeCallToMC with the Call Signalling Channel Transport Address of the 

endpoint containing the MC and CID = M of the conference. 
B2d) If the received CID matches the CID of a conference that endpoint 3 is currently 

participating in, it shall reject the call by sending Release Complete indicating that it 

is already in the conference. 
B3) If endpoint 3 accepts the invitation, endpoint 2 uses the transport address of the Control 
Channel provided in the Connect message to open the Control Channel with endpoint 3. 
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B4) The H.245 messages are then exchanged as described below: 

C 1 ) TerminalCapabilitySet messages are exchanged between the MC and endpoint 3 . 

C2) Using H.245 master-slave determination procedure, it is determined that endpoint 2 is 

already the active MC. The MC may then send the MCLocationlndication to the 

endpoint 3. 

C3) The MC shall send multipointModeCommand at this time to all the three endpoints. 

C4) The MC may send the terminalNumber Assign message to endpoint 3. If received, the 
endpoints shall use the 8-bit terminal number, and not use the 8-bit MCU number, from the 
16-bit number assigned as the low 8 bits of the SSRC field in the RTP header. These low 
8 bits in SSRC then identify the streams from a particular endpoints. 

C5) An endpoint can get the list of the other endpoints in the conference by sending the 
terminalListRequest message to the MC. The MC responds with the 
terminalListResponse. 

C6) Whenever a new endpoint joins the conference, the MC sends the terminalNumber Assign 
message to endpoint 4 and terminalJoinedConference message to endpoints 1, 2 and 3. 

C7) Whenever an endpoint leaves the conference, the MC sends terminalLeftConference to the 
remaining endpoints. 

C8) The MC shall send the communicationModeCommand to all the endpoints in the 
conference. 

C9) Endpoint 1 and endpoint 2 will close their logical channels that were created during the 
point-to-point conference if they are inconsistent with the information contained in the 
communicationModeCommand. 

C 1 0) The logical channels can now be opened between the MC and the endpoints. 



Endpoint 2 (E2) Endpoint 3 (E3) 

Set-up (E3, CID = N, invite) 



Alerting/Call Proceeding 



Connect (E3 H.245 TA) 
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Figure 26/H.323 - MC invite signalling 



After a point-to-point conference has been established using procedures Al to A4, an endpoint 
(endpoint 1) that does not contain the active MC wishing to add another endpoint to the conference, 
shall use the following procedure: ^ 

B 1) Endpoint 1 sends a Set-up message to the MC (endpoint 2) with a new CRV indicating a call 
to endpoint 3 by providing the transport address of endpoint 3, CID - N, and 
conferenceGoal = invite. See Figure 27. 

B2) Endpoint 2 sends a Set-up message to endpoint 3 with CID = N and conferenceGoal = invite 
• according to the procedures in 8. 1 . 
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B3) During call signalling with endpoint 3, endpoint 2 shall pass Call Signalling messages 
received from endpoint 3, including Connect, to endpoint 1 (the original inviter). 

B4) Endpoint 3 has the same options, described previously, of either accepting or rejecting the 
invitation. 

B5) At some time after the completion of the call set-up procedure between endpoint 2 and 
endpoint 3, endpoint 2 shall send a Release Complete message to endpoint 1. 

B6) If endpoint 3 accepts the invitation, endpoint 2 uses the transport address of the Control 
Channel provided in the Connect message to open the Control Channel with endpoint 3. 

B7) The H.245 messages are then exchanged as previously described in procedures CI to CIO. 



Endpoint 1 (El) Endpoint 2 (E2) Endpoint 3 (E3) 

Set-up (E3, CID = N, invite) 
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Connect (E3 H.245 TA) 



Release Complete (cause) 



Set-up (E3, CID = N, invite) 
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Alerting/Call Proceeding 




Connect (E3 H.245 TA) 





Figure 27/H.323 - Non-MC invite signalling 



8.4.3.3 Direct Endpoint Call Signalling - Conference Join 

There are two cases of the conference join. First, an endpoint calls the endpoint which contains the 
active MC. Second, an endpoint calls an endpoint which is not the active MC. 

After a point-to-point conference has been established using procedures Al to A4, an endpoint 
(endpoint 3) wishing to join a conference may attempt to connect with the endpoint containing the 
active MC in the conference. In this case, the following procedure shall be used: 
Bl) Endpoint 3 sends a Set-up message to endpoint 2 with CID = N, and conferenceGoal = join 

according to the procedure in 8.1. See Figure 28. 
B2) If the CID matches the CID of an active conference in the MC, endpoint 2 (MC) has the 

following options: 

B2a) If it decides that endpoint 3 should be allowed to join the conference, it sends the 

Connect message with CID = N. 
B2b) If it decides that endpoint 3 should not be allowed to join the conference, it sends 
the Release Complete message with destinationBusy. 
B3) If the CID does not match the CID of an active conference in the MC, endpoint 2 shall send 

Release Complete indicating a bad CID. 
B4) If endpoint 2 allows the join, endpoint 2 opens the Control Channel with endpoint 3. 
B5) The H.245 messages are then exchanged as previously described in procedures CI to CIO. 
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Endpoint 2 (E2) Endpoint 3 (E3) 



Set-up (E3, CID = N, join) 



< — 


Alerting/Call Proceeding 






Connect (E2 H.245 TA) 


». 



T1 524 160-96 



Figure 28/H.323 - MC j oin signalling 

After a point-to-point conference has been established using procedures Al to A4, an endpoint 
(endpoint 3) wishing to join a conference may attempt to connect with an endpoint that does not 
contain the active MC in the conference. In this case, the following procedure shall be used: 
Bl) Endpoint 3 sends a Set-up message to endpoint 1 with CID = N, and conferenceGoal = join 

according to the procedure in 8. 1 . See Figure 29. 
B2) Endpoint 1 returns a Facility message indicating routeCallToMC with the Call Signalling 

Channel Transport Address of endpoint 2 (containing the active MC) and the CID = N of the 

conference. 

B3) Endpoint 3 then sends a Set-up message to endpoint 2 (MC) with CID - N and 
conferenceGoal = join as described in the previous conference join procedure. 

Endpoint 1 (El) End P° int 3 < E3 > Endpoint 2 (E2) 
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Alerting/Call Proceeding 



Connect (E2 H.245 TA) 



Figure 29/H.323 - Non-MC join signalling 
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8.4.3.4 Gatekeeper Routed Call Signalling - Conference Create 

In cases where the Gatekeeper routes the Call Signalling Channel and the H.245 Control Channel, 
the Gatekeeper should contain (or have access to) an MC or MCU. Procedures Al to A4 are used to 
establish the point-to-point call. During master-slave determination (A4b), if the Gatekeeper's 
terminalType is greater than the terminalType received from an endpoint in the 
masterSlaveDetermination message, the Gatekeeper may replace the endpoint's terminalType 
value with its own before forwarding the message to the destination endpoint. If the Gatekeepers 
terminalType is not greater than the terminalType of the endpoint, the Gatekeeper shall not modify 
the terminalType value. In effect, the Gatekeeper is performing the master-slave determination 
procedure with each endpoint. If the Gatekeeper wins the master-slave determination with both 
endpoints, the MC associated with the Gatekeeper shall be the active MC, otherwise, one of the 
endpoints shall be the active MC. 

8.4.3.5 Gatekeeper Routed Call Signalling - Conference Invite 

After a point-to-point conference has been established using procedures Al to A4 as modified 
above, an endpoint (endpoint 1 or 2) that does not contain the active MC wishing to add another 
endpoint to the conference, shall use the following procedure: 

Bl) Endpoint 1 sends a Set-up message through the Gatekeeper directed to endpoint 3 with a 

new CRV, CID = N, and conferenceGoal = invite. See Figure 30. 
B2) The Gatekeeper (MC) sends a Set-up message to endpoint 3 with CID = N and 

conferenceGoal = invite according to the procedures in 8.1. 
B3) During call signalling with endpoint 3, the Gatekeeper shall pass Call Signalling messages 

received from endpoint 3, including Connect, to endpoint 1 (the original inviter). 
B4) Endpoint 3 has the same options, described previously, of either accepting or rejecting the 

invitation. 

B5) At some time after the completion of the call set-up procedure between the Gatekeeper and 
endpoint 3, the Gatekeeper shall send a Release Complete message to endpoint 1. 

B6) If endpoint 3 accepts the invitation, the Gatekeeper uses the transport address of the Control 
Channel provided in the Connect message to open the Control Channel with endpoint 3. 

B7) The H.245 messages are then exchanged as previously described in procedures CI to CIO 
with the Gatekeeper taking part in all master-slave determination procedures as the active 
MC (C2). At this time, the Control Channels from the endpoints should be connected to the 
MC, and the MC should be in control of the conference. 
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Figure 30/H.323 - Gatekeeper routed invite signalling 
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8.4.3.6 Gatekeeper Routed Call Model - Conference Join 

After a point-to-point conference has been established using procedures Al to A4 as modified 
above an endpoint (endpoint 3), wishing to join a conference may attempt to connect with an 
endpoint that does not contain the active MC in the conference. In this case, the following procedure 
shall be used: 

Bl) Endpoint 3 sends a Set-up message through the Gatekeeper directed to endpoint 1 with 
CID = N, and conferenceGoal = join according to the procedure in 8. 1 . See Figure 3 1 . 

B2) If the CID matches the CID of an active conference in the MC, the Gatekeeper (MC) has the 
following options: 

B2a) If it decides that endpoint 3 should be allowed to join the conference, it sends the 

Connect message with CID = N to endpoint 3. 
B2b) If it decides that endpoint 3 should not be allowed to join the conference, it sends 

the Release Complete message with destinationBusy. 
B2c) The Gatekeeper may forward the Set-up message to endpoint 1. Endpoint 1 may 

respond with a Facility message indicating routeCallToMC or it may respond with 

a release complete. 

B3) If the CID does not match the CID of an active conference in the MC, the Gatekeeper shall 

send Release Complete indicating a bad CID. 
B4) If the Gatekeeper allows the join, the Gatekeeper uses the transport address of the Control 

Channel provided in the Set-up message to open the Control Channel with endpoint 3. 
B5) The H 245 messages are then exchanged as previously described in procedures CI to CIO 

with the Gatekeeper taking part in all master-slave determination procedures as the active 

MC (C2). At this time, the Control Channels from the endpoints should be connected to the 

MC, and the MC should be in control of the conference. 
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Figure 31/H.323 - Gatekeeper routed join signalling 



8.4.4 Supplementary services 

Provisions have been made within this* Recommendation to allow endpoints to the use the 
Supplementary Services as defined in Q.931-, Q.932- and the Q.95X-Series of Recommendations. 
These services shall use the Call Signalling Channel and Q.931 messages. These services may 
provide features such as hold, transfer, forward and redirection. 
Other methods of providing supplementary services are for further study. 
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8.5 Phase E - Call termination 

Either endpoint may terminate a call by the following procedure: 

1) It should discontinue transmission of video at the end of a complete picture, and then close 
all logical channels for video. 

2) It should discontinue transmission of data and then close all logical channels for data. 

3) It should discontinue transmission of audio and then close all logical channels for audio. 

4) It shall transmit the H.245 endSessionCommand message in the H.245 Control Channel, 
indicating to the far end that it wishes to disconnect the call and then discontinue H.245 
message transmission. It shall then close the H.245 Control Channel. 

5) It shall then wait to receive the endSessionCommand message from the other endpoint and 
then shall close the H.245 Control Channel. 

6) If the Call Signalling Channel is open, a Release Complete message shall be sent and the 
channel closed. 

7) It shall clear the call by using the procedures defined below. 

An endpoint receiving endSessionCommand without first having transmitted it, shall carry out 
steps 1) to 7) above, except that in step 5), it shall not wait for the endSessionCommand from the 
first endpoint. 

Terminating a call may not terminate a conference; a conference may be explicitly terminated using 
an H.245 message (dropConference). In this case, the endpoints shall wait for the MC to terminate 
the" calls as described above. 

8.5.1 Call clearing without a Gatekeeper 

In networks that do not contain a Gatekeeper, after steps 1) to 6) above, the call is terminated. No 
further action is required. 

8.5.2 Call clearing with a Gatekeeper 

In networks that contain a Gatekeeper, the Gatekeeper needs to know about the release of 
bandwidth. After performing steps 1) to 6) above, each endpoint shall transmit an H.225.0 
Disengage Request (DRQ) message 3) to its Gatekeeper. The Gatekeeper shall respond with a 
Disengage Confirm (DCF) message 4). After sending the DRQ message, the endpoints shall not send 
further unsolicited IRR messages to the Gatekeeper. See Figure 32. At this point, the call is 
terminated. Figure 32 shows the direct call model; a similar procedure is followed for the Gatekeeper 
routed model. 

The DRQ and DCF messages shall be sent on the RAS Channel. 
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NOTE - Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper. 

Figure 32/H.323 - Endpoint initiated call clearing 
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8.5.3 Call clearing by Gatekeeper 

The Gatekeeper may terminate call by sending a DRQ to an endpoint. See Figure 33. The endpoint 
shall immediately follow steps 1) through 6) from above and then reply to the Gatekeeper with DCF. 
The other endpoint, upon receiving endSessionCommand, shall follow the procedure described 
above. Figure 33 shows the direct call model; a similar procedure is followed for the Gatekeeper 
routed model. 

If the conference is a multipoint conference, the Gatekeeper should send a DRQ to each endpoint in 
the conference, in order to close the entire conference. 
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NOTE - Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper. 

Figure 33/H.323 - Gatekeeper initiated call clearing 
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8.6 Protocol failure handling 

The underlying reliable protocol of the H.245 Control Channel uses appropriate effort to deliver or 
receive data on the channel before reporting a protocol failure. Therefore, if a protocol failure is 
reported on the channel, the H.245 Control Channel, and all associated logical channels shall be 
closed. This shall be done following the procedures of Phase E, as if the other endpoint had issued 
the H.245 endSessionCommand. This includes transmission of the DRQ message to the Gatekeeper 
and termination of the Call Signalling Channel. In the case where the failure is detected by the MC 
in a multipoint conference, the MC shall send terminalLeftConference messages to the remaining 
terminals. It is up to the implementation whether or not to try to re-establish the call without user 
intervention. In any case, this would appear to the other endpoint (and the Gatekeeper) as a new call. 

The Call Signalling Channel also uses an underlying reliable protocol. Depending on the routing of 
the Call Signalling Channel, either the Gatekeeper or an endpoint may detect the protocol failure. If 
the Gatekeeper detects the failure, it shall attempt to re-establish the Call Control Channel. This 
implies that the endpoint shall always have the ability to establish a channel on its Call Signalling 
Channel Transport Address. Failure of the Call Signalling channel shall not change the Q.931 call 
state. After re-establishment of the Call Signalling Channel, the Gatekeeper may send a Status 
message to request the call state of the endpoint to assure that they are in synchronization. 

If the endpoint detects the failure, the endpoint may choose to terminate the call as described in 
Phase E, or it may attempt to re-establish the Call Signalling Channel as described above. 

If, during a call, an endpoint wants to determine if the other endpoint is still functioning and 
connected, it may send the H.245 roundTripDelayRequest. Since H.245 Control Channel is carried 
on a reliable channel, this will result in a response from the other endpoint or an error from the 
transport interface. In the latter case, the procedures described above shall be used. An endpoint in a 
multipoint conference may use the same mechanism; however, it will learn only whether it still has a 
connection to the MC. Note that it is possible for an endpoint to have an error-free connection with 
the MC but still be receiving no audio or video from the rest of the terminals in the conference. 

9 Interoperation with other terminal types 

Interoperation with other terminals shall be accomplished through the Gateway. See 6.3. 
9.1 Speech only terminals 

Interoperation with speech only terminals (telephony) over the ISDN or GSTN can be provided by: 

1) using a H.323-ISDN speech Gateway; 

2) using a H.323-GSTN speech Gateway. 
The Gateway should consider the following issues: 
- Audio code conversion: 

- ISDN: If desired, since ISDN uses G.71 1 . 

- GSTN : from analogue to G.7 1 1 . 
Bit stream conversion: 

- ISDN: H.225.0 to/from unframed. 

- GSTN: generate H.225.0. 
Control conversion (generate H.245). 
Call Control Signalling conversion. 

DTMF tone conversion to/from H.245 userlnputlndication message. 
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9.2 Visual telephone terminals over the ISDN (H.320) 

Interoperation with visual telephone terminals over the ISDN (H.320) can be provided by: 

using a H.323-H.320 Gateway. 
The Gateway should consider the following issues: 

Video format conversion. (If desired, H.261 is mandatory for both terminal types.) 

Audio code conversion. (If desired, G.7 1 1 is mandatory for both terminal types.) 

- Data protocol conversion. 

Bit stream conversion. (H.225.0 to/from H.221 .) 
Control conversion. (H.245 to/from H.242.) 
Call Control Signalling conversion. 

SBE Number conversion to/from H.245 userlnputlndication message. 

9.3 Visual telephone terminals over GSTN (H.324) 

Interoperation with visual telephone terminals over the GSTN (H.324) can be provided by two 
methods: 

1) using a H.323-H.324 Gateway; 

2) using a H.323-H.320 Gateway, assuming that there exists an ISDN/GSTN Interworking Unit 
in the network. 

The Gateway should consider the following issues: 

Video format conversion. (If desired, H.261 is mandatory for both terminal types.) 

- Data protocol conversion. 

Audio code conversion. (G.711 is mandatory for H.323 terminal, G.723 is mandatory for 
H.324 terminal.) 

Bit stream conversion. (H.225.0 to/from H.223.) 
Call Control Signalling conversion. 

9.4 Visual telephone terminals over mobile radio (H.324/M) 

For further study. 

9.5 Visual telephone terminals over ATM (H.321) 

Interoperation with visual telephone terminals over ATM networks (H.321) can be provided by two 
methods: 

1) using a H.323-H.321 Gateway; 

2) using a H.323-H.320 Gateway, assuming that there exists an 1.580 ISDN/ATM Interworking 
Unit in the network. 

The Gateway should considerthe following issues: 

Video format conversion. (If desired, H.261 is mandatory for both terminal types.) 

- Data protocol conversion. 

Audio code conversion. (If desired, G.7 1 1 is mandatory for both terminal types.) 
Bit stream conversion. (H.225.0 to/from H.221 .) 
Control conversion. (H.245 to/from H.242.) 
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Call Control Signalling conversion. 

9.6 Visual telephone terminals over guaranteed quality of service LANs (H.322) 
Interoperation with visual telephone terminals over Guaranteed Quality of Service LANs (H.322) 
can be provided by: 

using a H.323-H.320 Gateway, assuming that there exists a GQOS LAN-ISDN Gateway in 
the network. 

The Gateway should consider the following issues: 

Video format conversion. (If desired, H.261 is mandatory for both terminal types.) 
Data protocol conversion. 

Audio code conversion. (If desired, G.7 1 1 is mandatory for both terminal types.) 
Bit stream conversion. (H.225.0 to/from H.221.) 
Control conversion. (H.245 to/from H.242.) 
Call Control Signalling conversion. 

9.7 Simultaneous voice and data terminals over GSTN (V.70) 

Interoperation with Simultaneous Voice and Data Terminals over GSTN (V.70) can be provided by: 

using a H.323-V.70 Gateway. 
The Gateway should consider the following issues: 

Audio code conversion. (G.71 1 to/from Annex A/G.729.) 
- Data protocol conversion. 

Bit stream conversion. (H.225.0 to/from V f 76/V.75.) 

Control conversion. (Both terminals use H.245.) 

Call Control Signalling conversion. 

9.8 T.120 terminals on the LAN 

An H.323 terminal that has T.120 capability should be capable of being configured as a T.120-only 
terminal which listens and transmits on the standard T.120 well-known TSAP Identifier. This will 
allow the T.120 capable H.323 terminal to participate in T.120-only conferences. 
A T.120-only terminal on the LAN shall be able to participate in the T.120 portion of multipoint 
H.323 conferences. See 6.2.7.1. 

10 Optional enhancements 

10.1 Encryption 

For further study. 
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11 Maintenance 



11.1 Loopbacks for maintenance purposes 

Some loopback functions are defined in Recommendation H.245 to allow verification of some 
functional aspects of the terminal, to ensure correct operation of the system and satisfactory quality 
of the service to the remote party. 

The systemLoop request and iogicalChannelLoop request shall not be used. The mediaLoop 
request is optional. An endpoint that receives the maintenanceLoopOffCommand shall turn off all 
loopbacks currently in effect. 
For the purpose of loopbacks, two modes are defined: 

a) Normal operation mode: No loopback. Indicated in a) of Figure 34. This shall be the default 
mode, and the mode entered when the maintenanceLoopOffCommand is received. 

b) Media loop mode: Loopback of media stream at the analogue I/O interface. Upon receiving 
the mediaLoop request as defined in Recommendation H.245, loopback of the content of 
the selected logical channel shall be activated as close as possible to the analogue interface 
of the video/audio codec towards the video/audio codec, so that decoded and re-coded media 
content is looped, as indicated in b) of Figure 34. This loopback is optional. It should be 
used only when a single logical channel containing the same media type is opened in each 
direction. Operation when multiple channels are opened in the return direction is undefined. 
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Figure 34/H.323 - Loop back 



A Gateway to H.324 and H.310, which receives an H.245 systemLoop request, H.245 
IogicalChannelLoop request, or a Gateway to H.320, which receives an H.230 Dig-Loop command 
from an SCN endpoint may perform the appropriate loopback function within the Gateway. The 
Gateway shall not pass these requests to the LAN endpoint. A Gateway to H.324/H.310, receiving 
H.245 mediaLoop from an SCN endpoint shall pass the request to the LAN endpoint. A Gateway to 
H.320, receiving H.230 Vidrloop or Au-loop command from an SCN endpoint shall convert it to the 
appropriate H.245 mediaLoop request amhsend it to the LAN endpoint. 

A Gateway H.320, which receives an H.245 mediaLoop request from a LAN endpoint shall convert 
it to the appropriate H.230 Vid-loop or Au-loop command and send it to the SCN endpoint. 
A Gateway to H.324 and H.310, may send an H.245 systemLoop request or H.245 
IogicalChannelLoop request to the SCN endpoint. A Gateway to H.320 may send an H.230 
Dig-Loop command to the SCN endpoint. If a LAN endpoint is in a call to the SCN endpoint, the 
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audio and video sent to the LAN endpoint may be the looped back audio or video, pre-recorded 
audio or video message indicating the loopback condition, or no audio or video. 



11.2 Monitoring methods 

All terminals shall support the Information Request/Information Request Response (IRQ/IRR) 
message of Recommendation H.225.0. The Information Request Response message contains the 
TSAP Identifier of all channels currently active on the call, including T.120 and H.245 control, as 
well as audio and video. This information can be used by third party maintenance devices to monitor 
H.323 conferences to verify system operation. 



ANNEX A 

H.245 messages used by H.323 endpoints 

The following rules apply to the use of H.245 messages by H.323 endpoints: 

An endpoint shall not malfunction or otherwise be adversely affected by receiving H.245 
messages that it does not recognize. An endpoint receiving an unrecognized request, 
response, or command shall return "function not supported". (This is not required for 
indications.) 

The following abbreviations are used in Tables A. 1 to A. 1 1 : 
M Mandatory 
O Optional 

F Forbidden to transmit 

A message marked as mandatory for the receiving endpoint indicates that the endpoint shall 
accept the message and take the appropriate action. A message marked as mandatory for the 
transmitting endpoint indicates that the endpoint shall generate the message under the 
appropriate circumstances. 



Table A.1/H.323 - Master-slave determination messages 



Message 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint 
Status 


Determination 


M 


M 


Determination Acknowledge 


M 


M 


Determination Reject 


M 


M 


Determination Release 


M 


M 
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Table A.2/H.323 - Terminal capability messages 



IVf PCC5KJP 
ITlCSSAgv 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint 
Status 


Capability Set 


M 


M 


Capability Set Acknowledge 


M 


M 


Capability Set Reject 


M 


M 


Capability Set Release 


M 


M 



Table A.3/H.323 - Logical channel signalling messages 



Message 


Receiving 
Endpoint 
Status 


i ransmiinng 
Endpoint 
Status 


Open Logical Channel 


M 


M 


Open Logical Channel Acknowledge 


M 


M 


Open Logical Channel Reject 


M 


M 


Open Logical Channel Confirm 


M 


M 








Close Logical Channel 


M 


M 


Close Logical Channel Acknowledge 


M 


M 








Request Channel Close 


M 


0 


Request Channel Close Acknowledge 


0 


0 


Request Channel Close Reject 


0 


M 


Request Channel Close Release 


0 


M 



Table A.4/H.323 - Multiplex table signalling messages 



Message 


Status 


Multiplex Entry Send 


F 


Multiplex Entry Send Acknowledge 


F 


Multiplex Entry Send Reject 


F 


Multiplex Entry Send Release 


F 



Table A>5/H.323 - Request multiplex table signalling messages 



i ■ M v 1 

Message 


Status 


Request Multiplex Entry 


F 


Request Multiplex Entry Acknowledge 


F 


Request Multiplex Entry Reject 


F 


Request Multiplex Entry Release 


F 
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Table A.6/H.323 - Request mode messages 



Message 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint Status 


Request Mode 


M 


0 


Request Mode Acknowledge 


M 


0 


Request Mode Reject 


0 


M 


Request Mode Release 


0 


M 


Table A.7/H.323 - Round trip delay messages 


Message 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint 
Status 


Round Trip Delay Request 


M 


O 


Round Trip Delay Response 


O 


M 


Table A.8/H.323 - Maintenance loop messages 


Message 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint Status 


Maintenance Loop Request 






System Loop 


F 


F 


Media Loop 


0 (Note) 


0 (Note) 


Logical Channel Loop 


F 


F 


Maintenance Loop Acknowledge 


0 


0 


Maintenance Loop Reject 


0 


M 


Maintenance Loop Command Off 


M 


0 


NOTE - Mandatory in Gateways. 
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Table A.9/H.323 - Commands 



Message 


Receiving 
Endpoint 
Status 


Transmitting 
Endpoint 
Status 


Send Terminal Capability Set 


M 


M 


Encryption 


0 


0 


Flow Control 


M 


0 


End Session 


M 


M 


Miscellaneous Commands 






Equalize Delay 


0 


0 


Zero Delay 


0 


0 


Multipoint Mode Command 


M 


o 


Cancel Multipoint Mode Command 


M 


o 


Video Freeze Picture 


M 


0 


Video Fast Update Picture 


M 


0 


Video Fast Update GOB 


M 


0 


Video Fast Update MB 


M 


0 


Video Temporal Spatial Trade Off 


0 


0 


Video Send Sync Every GOB 


0 


0 


Video Send Sync Every GOB Cancel 


0 


0 


MCLocationlndication 


M 


0 


Terminal ID Request 


0 


0 


Terminal List Request 


0 


0 


broadcast Me 


0 


0 


cancel Broadcast Me 


0 


0 


Make Terminal Broadcaster 


0 


0 


Send This Source 


0 


0 


Cancel Send This Source 


0 


o 


Drop Terminal 


O 


o 


Make Me Chair 


O 


o 


Cancel Make Me Chair 


O 


o 


Drop Conference 


O 


o 


Enter H.243 Password 


0 


0 


Enter H.243 Terminal Id 


O 


o 


Enter H.243 Conference ID 


0 


o 


Request Terminal ID V 


O 


o 


— — 

Terminal ID Response 


o 


KJ 


Terminal List Response 


0 


0 


Video Command Reject 


0 


0 


Make Me Chair Response 


0 


0 
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Table A.10/H.323 - Conference mode commands 



Message 


Receiving 
Endpoint 
Status 


1 raiisniiiung 
Endpoint 
Status 


Communication Mode Command 


M 


O 


Communication Mode Request 


0 


O 


Communication Mode Response 


0 


0 


Table A.11/H.323 - Indications 




Receiving 
Endpoint 
Status 


Transmitting 
Endpoint 
Status 


Function Not Supported 


M 


M 


Miscellaneous Indication 






Logical Channel Active 


0 


O 


Logical Channel Inactive 


0 


O 


Multipoint Conference 


M 


O 


Cancel Multipoint Conference 


M 


0 


Multipoint Zero Comm 


0 


o 


Cancel Multipoint Zero Comm 


0 


o 


Multipoint Secondary Status 


0 


o 


Cancel Multipoint Secondary Status 


O 


o 


Video Indicate Ready to Activate 


0 


0 


Video Temporal Spatial Trade Off 


0 


o 


SBE Number 


0 


o 


Terminal Number Assign 


M 


o 


Terminal Joined Conference 


0 


o 


Terminal Left Conference 


0 


o 


Seen By At Least One Other 


0 


0 


Cancel Seen By At Least One Other 


0 


o 


Seen By All 


0 


0 


Cancel Seen By All 


0 


0 


Terminal You Are Seeing 


0 


0 


Request For Floor 


0 


0 


Jitter Indication 


o 


0 


H.223 Skew Indication 


F 


F 


H2250MaximumSkewIndication 


0 


M 


New ATM Virtual Channel Indication 


F 


F 


User Input 


M(for 0-9,* 
and #) 


M (for 0-9, 
*and#) 



Non-standard commands, requests, etc. are allowed. 
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APPENDIX I 
Processing of Q.931 messages in Gateways 

The Gateway shall terminate the Q.931 Call Signalling Channel between an H.323 endpoint and the 
Gateway on one hand and the call signalling channel (if any) between the Gateway and the SCN 
endpoint on the other. The following applies only if the SCN side supports a call signalling protocol 
such as Q.931 orQ.2931. 

The Gateway shall conform to the call signalling procedures recommended for the SCN side 
independent from the LAN side. The Gateway shall conform to the call signalling procedures of this 
Recommendation for the LAN side independent from the SCN side. 

In addition, call signalling messages received from one side (LAN/SCN) may require forwarding to 
the other side (SCN/LAN). Some forwarded messages may contain information elements or parts of 
information elements which are unmodified or uninterpreted by the Gateway. Other forwarded 
messages may contain information elements or parts of information elements may be added or 
removed by the Gateway, as needed. 

In the following, an overview of the actions to be taken by the gateway in response to Q.931 
messages and the information elements, is provided. Messages and information elements that are 
forbidden in Recommendation H.225.0 are not considered. 
Q.931 messages originating on the H.323 side: 

A SETUP message side shall lead to initiation of call set-up procedure for the SCN side. 

A RELEASE COMPLETE shall lead to initiation of the call disconnect as defined for the 

SCN side. 

A CALL PROCEEDING message shall be forwarded to the SCN side. This shall not be 
done if a CALL PROCEEDING has been sent before to the SCN in compliance to the 
respective SCN specification (Q.93 1 in the ISDN case). 

A CONNECT message shall be forwarded to the SCN side upon receipt from an H.323 
endpoint. 

A CONNECT ACKNOWLEDGE message shall be forwarded to the SCN side upon receipt. 
This shall not be done if CONNECT ACKNOWLEDGE has been sent before to the SCN m 
compliance to the respective SCN specification. If the Gateway has sent a CONNECT to an 
H.323 endpoint and has not received the corresponding CONNECT ACKNOWLEDGE 
from the H 323 endpoint within the time frame required for successful completion of the 
call, it shall generate the CONNECT ACKNOWLEDGE to the SCN side as appropriate to 
comply to the SCN call set-up procedures. 

Messages for supplementary services (FACILITY, HOLD, HOLD ACKNOWLEDGE 
HOLD REJECT, RETRIEVE, RETRIEVE ACKNOWLEDGE, RETRIEVE REJECT and 
the INFORMATION messages) that are not processed by the Gateway, shall be forwarded 
to the SCN side. 

All messages forbidden to be originated from an H.323 endpoint shall be generated by the 
Gateway autonomously as requirea by the SCN protocol. 
The information elements of the respective messages are to be converted as follows: 

The contents of connection specific information elements (such as Call Reference Value) 
shall be adapted as required by the SCN protocol. 
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Information elements that are not in use on the H.323 side shall be generated by the 
Gateway as required by the SCN protocol. 

Translation of other information elements shall be done as required by the SCN protocols 
and procedures. Where interoperability is not an issue, conversion is left to the discretion of 
the manufacturer. 

Only the user-data part of the user-user information element shall be forwarded to the SCN 
side. It shall be re-encoded following Figure 4-36/Q.931 and Table 4-26/Q.931. 

All Q.931 messages originating on the SCN side are forwarded to the H.323 endpoint without 
modification except for the following: 

Messages forbidden by Recommendation H.225.0 shall not be passed to the H.323 side. 

The call reference value is mapped to the appropriate value for the H.323 side. 

The user data field is copied into the corresponding ASN.l user-user information element 

structure. 

The user-user information element structure shall be generated according to the specification 
in Recommendation H.225.0. 
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